Home > Uncategorized > Improving Ajax performance and usability by using request based priority.

Improving Ajax performance and usability by using request based priority.

With Ajax based applications becoming more and more popular, the usability and performance of such application are critical. Asynchronous (Ajax) requests might significantly reduce performance of an application, and worse, impact it usability. Fortunately, request based priority (RBP) can significantly improve the performance.

How? Before I go into the details of RBP, let me first explain the problem. With the advent of Ajax, application can now update the page using asynchronous requests, and execute without the need of any user interaction. The frequency of such requests to a server might be often (like every 10 seconds) to very often (every second). That also apply to Comet application, independently of the polling mechanism you are using. Hence your application might perform pretty well for a small number of users, but as soon as you go into production, suffer serious performance problems. What I means here by performance problems is the response from the server to an Ajax request might take more time than you have expected when your were testing your application. Event if the user didn’t initiated the request, your application might suddenly suffer usability problem because the page is not updated as fast as it should. A typical example is a chat application where too many Ajax clients try to simultaneously get all the messages from the chat room, and a fairly large number of clients also try to join the chat room. In that situation, the server might takes several seconds to proceed all the requests (read messages and connecting new users), with the disastrous effect of making the client side usability horrible (update to the chat room takes too much time). That situation apply to almost every Ajax based application under load. This is where request based priority (or resource consumption management) come into the picture.

Before going into the detail, let first explain how a WebServer works (not all works like that, but they all do something similar). When requests comes in, the WebServer put the request into a queue (see below)

1.jpg

When threads are available, they get a request from the queue and execute it. When no thread are available, then requests are waiting in the queue to be proceeded (in red below)

2.jpg

Now the normal behavior of a WebServer is to place the request at the end of the queue so every connection (or users) are equally serviced. There is some exception where if the http connection is using the keep-alive header (called persistent connection), the WebServer might execute keep-alived requests before accepting new connection. Independently of how the request is executed, an Ajax application which needs to update its content real time (or very fast) might face a situation where the request is placed at the end of the queue, delaying the response from milliseconds to seconds. Hence, the usability of the Ajax application might significantly suffer if the server is getting under load and the queue is very large.

The solution is to use a Webserver that support resource consumption management, or in our case a request based priority mechanism that examines incoming requests and assign them to priority queues. Being able to prioritize requests might significantly improve the usability of an Ajax application. Why? Because with RBP, you can make sure that specific requests will always be executed first and never placed into a queue, by either being placed at the head of the queue or by being executed by another queue:

3.jpg

As an example, request taking the form of /myApp/getMail might always gets executed before /myApp/getAdressBook. The bad news is not all WebServer support request based priority. Fortunately for GlassFish users, Grizzly supports it via its RCM extension. Before going into the details on how to make in work in GlassFish, here is an experience my colleague Binu did for his talk at JavaOne this year. Mainly, Binu benchmarked the response time it take when RBP is enabled versus normal request processing. The test consist of a simple Ajax application that has a front page and a periodic Ajax update that simulates a stock ticker. The load driver used was Faban. In his experiment, 10% of the requests were front page and 90% requests were updates. The request cycle time for both were 2 seconds. The Front page is serviced by a privileged queue (see picture above) and the number of users was 3000.

Response time in secs.

Without Request Based Priority enabled
---------------------------------------

Front page avg. = 0.264
Front page 90% percentile = 0.5
Front page max. = 1.3

Update avg. = 0.2
Update 90% percentile = 0.3
Update max. = 1.23

With Request Based Priority enabled
-----------------------------------

Front page avg. = 0.021
Front page 90% percentile = 0.1
Front page max. = 0.19

Update avg. = 0.83
Update 90% percentile = 1.0
Update max. = 1.19 

As you can see, RBP can make a huge usability difference and improve responsiveness of your Ajax application.

Want to try it? Then download GlassFish v2 and do the following (you can use the admin-gui if you don’t want to edit the file manually):


% Install GlassFish
% Edit ${glassfish.home}/domains/domain1/config/domain.xml
% Under element http-listener, add the following line
  <property name="rcmSupport" value="true"/>
% Under jvm-options element, add:
  <jvm-options>-Dcom.sun.enterprise.web.ara.policyMetric= 
  /yourApp/requestURI1|0.5,/yourApp/requestURI2|0.3</jvm-options>
% Start GlassFish

In the example above, Grizzly will reserve 50% of the thread to request taking the form of /yourApp/requestURI1, 30% for yourApp/requestURI2 and the remaining for all other incoming requests. Technically, it will means three queues will be created and Grizzly will dispatch the request to them based on the request URI

In conclusion, being able to prioritize Ajax requests based on some policy rules (here request based) might significantly improve performance of your Ajax application. Always make sure the WebServer you will eventually deploy onto it has some support for request based priority.

technorati:

_uacct = “UA-3111670-1”;
urchinTracker();

Categories: Uncategorized
  1. Cedar Milazzo
    October 30, 2012 at 5:51 pm

    Jeanfrancois, once again thank you for posting very clear and useful information! This will help our performance significantly.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: