Single Page Interface, Google App Engine and 28Kb

DZone 's Guide to

Single Page Interface, Google App Engine and 28Kb

· Java Zone ·
Free Resource

In the eternal debate between client-centric and server-centric approaches in AJAX intensive applications, an aspect that always stands out against the server-centric approach is its high memory consumption, since the visual state is saved somehow on the server.

In intranet applications memory consumption is not a major problem since the maximum number of users tends to be discrete and limited.

However, if we want to build Single Page Interface (or AJAX-intensive in general) web sites for the general public, memory usage on the server becomes very important since the number of simultaneous users can be extremely variable and can certainly be very high if we speak of a very popular website.

To previous reflection we must add the proliferation of cloud computing options where the application will run on multiple nodes at once and with the possibility of "elastic scalability", that is nodes being added automatically when the application load increases.

The problem of memory consumption on the server is especially relevant when we do not have session affinity (sticky sessions), as in Google App Engine , and therefore the visual state saved on the server is capable of being serialized and replicated between the nodes running the application, the higher the client's visual state stored on the server the greater the amount of data that will be transported between nodes.

Google App Engine (GAE) is one of the Achilles heels of server-centric frameworks due largely to the replication of sessions as the only option of GAE. These frameworks work much more "fluent" with session affinity (although there are other constraints that hinder GAE usage). Looking at the list of frameworks that work in GAE, there are not many server-centric and its presence in the list does not necessarily mean that they are effective working with heavy use of AJAX (because of server-centric AJAX based applications are usually more stateful than page based).

ItsNat also supports Google App Engine since version 0.7 as you can see in that list, as you sure know ItsNat is clearly server-centric (although it can be combined with client libraries as it was recently shown here at JavaLobby).

Therefore we have a problem, the server-centric approach, for example in the case of ItsNat, is perhaps the best option for creating dual Single Page Interface web sites, that is they can also run as paged if we disable JavaScript or are indexable by search engines without resorting to make two versions, however server-centric seems a large consumer of memory and therefore data memory should be serialized to be shared between the nodes of a cloud as GAE.

Another option is possible, basically the technique is not to save the visual state in the session keeping in the client (in URLs) the necessary information to reconstruct the visual state of the server when GAE determines a node change for a web request from the same client.

Although this option is viable (and it works in the case of ItsNat) a page reload happens when the target node changes because visual state is not there because there is no visual state propagation by sessions (fortunately node changing is not very common if the requests are very consecutive), and therefore with such a strategy we could talk about "semi" Single Page Interface web sites.

So if we want true Single Page Interface in GAE we must rethink the problem of memory.

Do we really need lots of memory on the server?

ItsNat can avoid static parts of the page, these static parts are not manipulated by program code and thus can be cached in plain text shared among all users, and avoid being instantiated as DOM for each client. The template system of ItsNat helps this caching with a simple special attribute.

But this is not enough, if we have to change a text node some part of the subtree containing this text node must be in memory in spite of this node is no longer to be modified.

With the introduction of the technique "disconnected nodes" in ItsNat v1.1 everything changes, we can now remove a DOM subtree on the server and leave it intact on the client (you can resynchronize the two sides again if you like) this way we can avoid storing whole areas of the page as DOM if these areas are not going to be changed anymore (usually, they are replaced by others). This technique was already in the article of hybrid programming client / server but the article quoted above did not focus on the issue of memory but rather how client JavaScript code can collaborate.

The next step is:

Is it possible to achieve a drastic reduction of memory on Single Page Interface web sites and get high performance in Google App Engine with session replication?

The answer is YES!

However it has been necessary to publish ItsNat v1.1.1 to solve some important problems in GAE with session replication enabled, the most important is to get rid of the need of the cleaner thread of Batik DOM (in which is based ItsNat extending it to different uses). This thread can not be created because GAE does not support the creation of threads, on the other hand, the caching technique used by Batik DOM retains with weak references lost nodes, unfortunately they were unnecessarily serialized increasing the size of serialized data. ItsNat v1.1.1 rewrites that part of Batik DOM avoiding weak references the need for this thread in the background.

ItsNat v1.1.1 adds another interesting method ItsNatServletContext.setSessionSerializeCompressed (boolean) that serves to automatically compress (with gzip) the serialized data saved in session, reducing the amount of data that GAE (or any other environment or session replication serialization for failover) is going to transport between nodes. Other interesting method is ItsNatServletContext.setSessionExplicitSerialize (boolean)  intended to simulate the behavior of cloud environments such as GAE but in a single instance.

What if we take all this into practice?

This demo is a prototype of a Single Page Interface web site, we apply the aforementioned techniques to save memory and allow the visual state is serialized in the session (enabling data compression).

Navigating to the state that consumes the most memory: Electronic / TV / LCD TV (that displays the list of products), if we save this page, the resulting file occupies 151Kb of plain markup, as DOM objects that would take significantly more memory for obvious reasons.

Web Site Detail

But through the Datastore Viewer management console of GAE we can know what the size of the serialized session shared between instances is no more than 28Kb

Datastore Viewer Detail

Conclusion: Can your server-centric Single Page Interface web site be infinitely scalable? Can you live in the clouds?




Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}