Since the advent of the web as a medium for business applications, it has generally been accepted that the user interfaces available over the web are below standard when compared to traditional user interface applications. Yet the thin client advantages of web applications have mostly outweighed the usability requirements, so the majority of web applications today represent a compromise between usability and ability to deliver the interface over the web.
Yet significant business advantages are available if a solution can be found to deliver rich user interfaces over the web to satisfy customer expectations for no-compromise interfaces and more interactive features. Ajax Comet is a technique that is now being used to implement such break-through web applications. When Google released their Ajax based gmail application, it represented a quantum leap in the usability of web mail. Not only did gmail render all other web mail clients obsolete, but it also attracted hundreds of thousands of new clients away from their traditional desktop mail client. Google have continued to drop such “bombshells” on their competitors with Ajax based chat, maps and calendars, while many companies such as Zimbra and Backpack are using Ajax to invent new ways to approach traditional applications.
The quality of these new web applications is such that the techniques they use have been termed Web 2.0 to indicate a major increment in the functionality of the web. So the bar has been lifted with customer expectations of the usability of web applications and currently there is still significant competitive advantage to be gained by meeting those expectations. However, given the rapid uptake of Ajax technologies, delay in deployment could result in the need to play catch up to a competitor who has made a quantum leap in usability of their web application.
This paper introduces the Ajax Comet techniques used to build web 2.0 applications and describes the possibly significant impact they can have on the web application server resource requirements. It shows how a naive deployment of web 2.0 applications could require a 10 fold increase in the size of the application server farm.
The essential problem with Web 1.0 applications (traditional ) is that they are page based. In response to a click from a user, a page is down loaded from the server, along with a set of images and other resources. While the user is interacting with a page, only the resources downloaded with that page may be used to as the basis for interaction with the user. Thus a compromise must be made between size of the download and availability of data and it is generally not possible to access:
large data sets (eg postcodes database, product catalogs)
previously unselected data (eg. a different email folder or product catalog)
data that has changed after the page download (eg prices, bids, email arrival).
Once a user has reached the limits of the downloaded resources, another entire page must be downloaded with another set of resources that attempt to anticipate the users expected interactions. The result is an interface that is split into discrete interactions, each only approximating the average users expectations.
Dynamic HTML (DHTML) is the best-practice use of the available standards for displaying and interacting with a HTML document using javascript and DOM (Document Object Model). DHTML provides the visual effects for web applications such as drag and drop, hides, reveals, interactive validation. While such visual effects (when used without excess) are fundamental to Web 2.0, on their own they do not resolve the essential problem of Web 1.0 as they do not have access to any additional data or events. DHTML allows the available downloaded data to be used in a more interactive way, but it is only interact with a limited cache of data downloaded with the page and suffers from the same size and anticipation-based compromises of Web 1.0 applications.
Literally the term Ajax derives from Asynchronous Javascript And XML, but a strict definition is no longer appropriate and the term is now used to describe a large set of techniques used to break out of the page-based restrictions of Web 1.0. Specifically, a web page within an Ajax application has the ability to contact a server to request additional resources in response to user interaction. It is these asynchronous requests made in the background that allow Ajax applications to load:
the postcode for a place name, or a place name for a postcode.
new map tiles as a user drags a Google map.
email content as a user select an email subject.
The results of these requests are dynamically integrated into the currently displayed HTML document without the need for a full page reload. The result is an interface that is continuous and can be based on explicitly targeted, complete data rather than a constrained anticipated data subset.
In other words, Ajax allows Web 2.0 applications to access data in a way that is completely normal for non-web based client-server applications. The fact that web applications have succeeded to date without this fundamental ability is a strong indication of the benefits of the web deployment model. However, now that interactive access data is available within web applications, it is unlikely that users will continue to accept the interface compromises in return for access via the web.
Ajax gives the browser client the ability to request more data from a server, but it does not give the server the ability to asynchronously send data to the client. Thus while a client can ask the server for the body of a known email, the server is unable to inform the client of any newly arrived emails unless the client specifically asks. Thus for data sets that may change without interaction from the current user (eg prices, bids, chat, email) and Ajax client must poll the server to discover any changes to the data set.
With polling, a latency vs throughput compromise must be reached between frequent polling, which will waste CPU and bandwidth if there are no events; and infrequent polling, which efficiently accesses the data but with potential delays.
Comet is an Ajax technique (also called long polling) that uses the ability of a server to hold poll requests until either a timeout or an event occurs. A server that is holding a poll request has the ability to send a response at anytime to communicate an event to the client. So long as the client browser supports multiple connections to the server, Comet allows efficient two way communication between Ajax client and server.
There have been and are many contenders in the technology race to provide rich interactive user interfaces that can be deployed over the web: Java Applets; Java web start, Flash, native plugins, web services clients. Yet all of these have failed to achieve any significant uptake nor any level of acceptance as the defacto standard for rich web applications. They have all failed due to much the same reasons, namely that complications of installation, portability, proxies, firewalls and incompatible versions have negated some of the basic premises of applications delivered over the web, that they be available on any browser, on any device, any where and that they present a familiar interface that is intuitively usable.
Against these technological solutions is Ajax. Ajax is not a technology, but rather a set of techniques to use the technology currently available within web browsers to the best possible advantage. Ajax and the related Comet technique, are just best-of-bread uses of the open standards that are available in vast majority of commonly deployed web browsers.
In essence, because the average web consumer has already chosen not to install plugins or to widely accept applet or flash solutions present, they have already embraced the message of Open standards. Thus web consumers have already chosen Ajax as the rich web UI solution by their rejection of the non standard alternatives.
The current focus of Ajax web applications is on the various client side libraries and techniques that improve the interactivity of the application. However, the biggest challenge for successful deployment of an Ajax application is handling the different load profile that Ajax applications present to the application servers.
Ajax applications have the potential to reduce bandwidth requirements and server processing because only targeted data is sent to a client and the majority of the presentation burden can be shifted from the server to the client. However, to achieve this Ajax uses many small requests that can occur at any time, which is a significant contrast to the traditional load profile of fewer larger request coming in bursts associated with page boundaries.
The ability to scale web application servers to large numbers of simultaneous users has been based on the assumption web 1.0 traffic profiles. A burst of requests is received that represents a user accessing a page of the application, which is followed by a pause while the user reads the page, selects the next navigation link, completes a form or does nothing. During this pause, the server does not allocate a thread to the user and it may close the connection if resources are low.
Web 2.0 applications using Ajax techniques erode this assumption as they are able to issue new requests while a page is being read or a form is being completed. Thus the pauses between requests have become shorter and the thread-per-request model less efficient because a user will more frequently have requests being handled within the server.
Web 2. applications using Comet techniques totally invalidate the thread-per-request model. Comet applications use long standing requests that are held by the server to allow asynchronous responses to be sent by the server to the client. Thus an Ajax/Comet client will almost always have an outstanding request being held by the server so that a response can be sent in reaction to an asynchronous event on the server. Because the servlet API is synchronous, a thread must be allocated to these requests, even if the servlet handling them is idly waiting for an asynchronous event or a timeout.
The following table shows how a Web 2.0 Ajax Comet application can dramatically increase the requirements on a server that implements the thread-per-request model.
|
|
Formula |
Web 1.0 |
Web 2.0 + Comet |
|
Users |
u |
10000 |
10000 |
|
|
|
|
|
|
Requests/Burst |
b |
5 |
2 |
|
Burst period (s) |
p |
20 |
5 |
|
Request Duration (s) |
d |
0.200 |
0.150 |
|
Poll Duration (s) |
D |
0 |
10 |
|
|
|
|
|
|
Request rate (req/s) |
rr=u*b/20 |
2500 |
4000 |
|
Poll rate (req/s) |
pr=u/d |
0 |
1000 |
|
Total (req/s) |
r=rr+pr |
2500 |
5000 |
|
|
|
|
|
|
Concurrent requests |
c=rr*d+pr*D |
500 |
10600 |
|
Min Threads |
T=c |
500 |
10600 |
|
Stack memory |
S=64*1024*T |
32MB |
694MB |
The nature of the Comet requests results in a 20 times increase in the number of concurrent requests, threads and memory. This analysis only considers the resources of threads and stacks, but there are many other commonly pooled resources that are allocated during servlet request handling: input buffers, output buffers, character to byte converters, byte to character converters,etc. All of these may suffer an order of magnitude increase in usage in a web2.0 application.
Using the thread-per-request model, web 2.0 server farms would need to be at least 10 times their current sizes to handle the same number of users as a corresponding web 1.0 application.
Because of the blocking nature of the Java Servlet architecture, standard application servers all implement the thread-per-request model. We have seen that the thread-per-request model cannot be scaled to server web 2.0 Comet applications, so the servlet architecture must be extended if realistic server resources are to be achieved.
The Jetty Servlet Container has taken the lead in developing extension to the servlet mode to support support the asynchronous model required by web 2.0 Comet applications. The Jetty server has developed a Continuation mechanism that allows a requests to be suspended while waiting for an asynchronous event or timeout. This waiting is done without a thread allocated and thus avoids the excessive resource requirements of the thread-per-request model.
The following table indicates how Web 2.0 Comet applications can be implemented with continuations with only a modest increase in the server requirements:
|
|
Formula |
Web 1.0 |
Web 2.0 + Comet |
Web 2.0 + Comet + Continuations |
|
Users |
u |
10000 |
10000 |
10000 |
|
|
|
|
|
|
|
Requests/Burst |
b |
5 |
2 |
2 |
|
Burst period (s) |
p |
20 |
5 |
5 |
|
Request Duration (s) |
d |
0.200 |
0.150 |
0.175 |
|
Poll Duration (s) |
D |
0 |
10 |
10 |
|
|
|
|
|
|
|
Request rate (req/s) |
rr=u*b/20 |
2500 |
4000 |
4000 |
|
Poll rate (req/s) |
pr=u/d |
0 |
1000 |
1000 |
|
Total (req/s) |
r=rr+pr |
2500 |
5000 |
5000 |
|
|
|
|
|
|
|
Concurrent requests |
c=rr*d+pr*D |
500 |
10600 |
10700 |
|
Min Threads |
T=c T=r*d |
500 - |
10600 - |
- 875 |
|
Stack memory |
S=64*1024*T |
32MB |
694MB |
57MB |