See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/42804512

An Experimental Study of AJAX Application Performance

Article  in  Journal of Software · March 2008

DOI: 10.4304/jsw.3.3.30-37 · Source: DOAJ

CITATIONS READS

11 1,310

2 authors:

Clinton W. Smullen Iii Stephanie Smullen

University of Tennessee at Chattanooga University of Tennessee at Chattanooga
10 PUBLICATIONS   58 CITATIONS    16 PUBLICATIONS   85 CITATIONS   

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Stephanie Smullen on 03 June 2014.

The user has requested enhancement of the downloaded file.

30 JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008

An Experimental Study of AJAX Application

Performance
Clinton W. Smullen III
The University of Tennessee at Chattanooga, Chattanooga, TN, USA
[email protected]

Stephanie A. Smullen
The University of Tennessee at Chattanooga, Chattanooga, TN, USA
[email protected]

Abstract—An experimental study compared the In the typical web application, the browser presents an
performance of a real-life HTML application and an AJAX HTML page (with CSS and other components) to the
application that implemented the same user interface. A user. When the user clicks on a link or submits a form,
statistically significant number of trials were used to collect an HTTP request is made to the server (see Figure 1).
data on the performance of each when presented with the The server returns one or more HTTP responses
same tasks. Response size and service time performance containing the new HTML page, along with CSS,
measures were computed for the applications. AJAX graphics, etc. The current visible browser page is then
provided significant performance increase in response size,
entirely replaced by the new page. In an AJAX
thereby reducing bandwidth requirements. A typical user
would see a performance increase in the response size of application, the AJAX code, in response to user actions,
55%. AJAX provided a mean service time improvement of can perform behind-the-scenes server interactions unseen
approximately 16%. A typical user’s service time would by the user while the client-side user interface remains
improve by 21%. active. The AJAX code sends an XMLHttpRequest to
Index Terms—AJAX, performance, modeling, HTML the server (see Figure 2), which returns XML data. The
AJAX code then updates the visible page without
I. INTRODUCTION replacing the entire page. The user does not move from
page to page. Instead, the AJAX application responds
AJAX (Asynchronous JavaScript And XML) is a dynamically to the user's actions, downloading updates in
name applied to a set of technologies [1] designed to the background at the same time the user may be doing
improve web application responsiveness. This set other things. The technical basics for AJAX are well
includes HTML, CSS, Dynamic HTML, client-side understood. These basics (HTML, CSS, etc.) are covered
scripting (in either JavaScript/ECMAScript or Java), in many typical web programming courses and training
dynamic displays using the DOM model, data exchange sessions.
using XML, and synchronous or asynchronous data The use of AJAX in web programming is becoming
retrieval using XMLHttpRequest. A good reference is more widespread as newer versions of browsers support
Crane [2]. Mature commercial examples of the use of XMLHttpRequest objects. The popularity of certain
AJAX include Google Maps and Gmail; AjaxPatterns [3] social networking websites that use AJAX has also
now categorizes several hundred websites using mature increased the visibility of AJAX. However, very few
AJAX applications. studies have been published about the performance of
actual AJAX applications.
Using a “ridiculously simple” test application, Merrill
[4] found a 61% improvement due to the use of AJAX.
A commonly cited AJAX performance evaluation case
study is White [5]. This AJAX application transferred on
average 27% of the bytes that the traditional HTML
application transferred. White defined the “performance
increase” (PI) for a given measurement as
(HTML value – AJAX value) / (HTML value) * 100
Using this, White reported a 73% performance increase
for bytes transferred. Performance increases for the
AJAX application were also observed in the task times
taken by the users to accomplish the work. However, the
Fig 1. Classic web app Fig 2. AJAX web app effects of users’ skill levels and training (which could

© 2008 ACADEMY PUBLISHER

JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008 31

greatly affect the reported outcomes) were not assessed. server is Apache, and the application uses PHP 5.05 and
This is especially relevant since the two applications did custom database code to connect with the legacy SIS
not implement the same user interface. Nevertheless, the database. All pages returned are validated XHTML 1.1.
AJAX application required fewer bytes to be transferred
to carry out the tasks than did the HTML application and A. THE HTML APPLICATION
the users accomplished the assigned work in less time.
These time savings can be directly translated into The initial page loaded by a user contains the HTML
personnel cost savings. form used to prepare a query. There is a significant
To gain insight into the performance effects of AJAX, amount of “branding” overhead on this page; all of the
this report studies an HTML application and an AJAX University’s pages use the same layout, navigation items,
application which both implement the same user interface style sheet, and graphics. These common elements
with the same “look and feel”. consist of two graphical images, a CSS style sheet, and
JavaScript supporting the common page navigation links,
II. THE APPLICATION and total 15573 bytes. These elements are linked to the
HTML page and are static. For most browsers, they are
In [6], Smullen and Smullen compared the client-side downloaded once and cached, rather than being loaded
performance of a real-life production HTML application with each query and response.
and an AJAX application that implemented the same user A typical user would first load the HTML page
interface. Experimental data was collected on the containing the query form (27KB) and the common
performance of each when presented with the same set of elements (15.2KB). The user prepares a query and
one-hundred ten tasks. Performance measures were submits the query to a server application. The server
computed for the HTML application and for the AJAX application queries the SIS. The data extracted from the
application. In [7], Smullen and Smullen initiated a SIS is formatted as XML. The server process then reads
study of the impact of AJAX on the server. The current the XML data and applies an XSLT transform to produce
study extends these works by collecting data on a XHTML. The web server returns the XHTML as the
statistically significant sample size, including server response to the client.
performance results. The page returned as a response to a query links to the
The application studied in this paper is an existing common elements described above, contains the HTML
application that supplies real-time class information formatted list of courses in answer to the query (or a
extracted from a university student information system message if no results are produced), and also contains the
(SIS). The user specifies one or more selection criteria HTML form needed to make another query. As a result,
(such as department, course/section, meeting days, start even a query that produces no results has a response page
time/end time, location, instructor, open/closed) and the of about 27KB (plus the linked common elements).
application returns a list of courses meeting the specified
criteria and additional information about each of the B. THE AJAX APPLICATION
courses (including the title and current enrollment).
Figure 3 displays a typical query screen. The application An AJAX version of the HTML application was
uses a three tier model; the client communicates with the coded. The AJAX version uses JavaScript to run the user
web server, which communicates with the database interface and the XML handler. Care was taken to create
server. It is a production application, used daily by the same “look and feel” for the AJAX version as is used
students and faculty, not a “test” application. The web in the HTML version. Both the AJAX and the HTML
applications appear the same to the user at the
presentation level, so the presentation page structure is
the same, as are the graphics and common navigation
elements.
The Sarissa [8] libraries (version 0.9.6.1) were used to
code the AJAX application. Sarissa is an open-source
cross-browser set of libraries based on ECMAScript for
developing AJAX applications. It is representative of the
types of implementation libraries used for production
AJAX. The code and libraries downloaded to the client
to implement the AJAX interface for this application total
57KB.
For this investigation, the AJAX application uses only
synchronous AJAX XMLHttpRequest calls, for several
reasons. Choosing courses is inherently a serial process.
The next course selection often depends on the previous
Fig 3. Typical application screen selections made. Work in progress will assess
asynchronous AJAX performance, and this will appear in

© 2008 ACADEMY PUBLISHER

32 JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008

a future paper. Since the AJAX application reproduces Size in bytes of the initial elements downloaded
H
the same “look and feel” as the HTML application, the by the HTML web application
use of asynchronous calls was not needed. This Size in bytes of the ith HTML page loaded by the
application does not exploit AJAX capabilities to Pi
HTML web application
enhance the user experience, preload data, or use event- Pa Size in bytes of the average of the n Pi values
triggered processing. Hence this application represents
in some sense a worst case for AJAX – all of the Size in bytes of the initial elements downloaded
A
overhead but few of the advantages other than partial by the AJAX web application
page refresh. Size in bytes of the ith AJAX response handled
Ui
The existing server application was used for the by the AJAX web application
AJAX application. The central IT staff was extremely Ua Size in bytes of the average of the n Ui values
reluctant to modify a production system for this
experiment. Since the query results from the server The total bytes required to accomplish the task for each
application are available in XML form, the existing implementation is as follows.
production server application responds to an AJAX
XMLHttpRequest with the existing XML output; it skips HTML: total bytes = H + (P1 + P2 + … + Pn )
the XSLT transform and forwards the XML to the client. = H + n*Pa
The AJAX application fetches the XML data produced
by the production server process, which is then processed AJAX: total bytes = A + (U1 + U2 + … + Un)
in the AJAX client for display. = A + n*Ua
III. MODELING THE APPLICATIONS For most AJAX applications, H < A, Pa > Ua, and it is
likely that Pi > Ui for all i. If H > A and all Pi > Ui then
When a web application is contacted by a browser, an the AJAX application has an initial download time better
HTML page is loaded into the browser, including any than the HTML application, and the download time for
graphical elements, stylesheets, or other linked elements. each response is better as well. The AJAX application is
The client interacts with the user interface presented on clearly preferred over the HTML application. If H = A
the HTML page (such as by clicking a link or submitting and the Pi = Ui then the download times are equal. The
a form) which sends an HTTP request message to the greater effort and complexity required to code and
web server. The web server sends a new HTML page to maintain an AJAX application as compared to an HTML
the browser. This page replaces the previous page in the application would lead one to select the HTML
browser. application, unless the AJAX user interface presented
When an AJAX application is contacted by a browser, advantages to the user. If H < A and the Pi < Ui then the
an HTML page is loaded into the browser. This page HTML application is clearly preferred over the AJAX
contains the JavaScript needed to run the user interface application based on download times and application
and to issue XMLHttpRequest calls, the XML handler to issues, again unless the AJAX user interface presented
format and present the results, and any other elements significant advantages to the user.
needed for the user interface, such as HTML code and Since both of the applications discussed in section II
stylesheets. The client interacts with the user interface implement the same user interface, the cognitive
presented on the browser page (such as by clicking a requirements on the user to view a page or response and
link, submitting a form, or triggering an event). The to make a new request using the two interfaces are the
JavaScript code handles the user interface event, usually same. If asynchronous XMLHttpRequest calls were
generating an XMLHttpRequest message to the web supported, or if the AJAX user interface were
server. The web server sends XML data to the browser. significantly improved over the HTML user interface
This XML data is handled by the JavaScript code and then for a particular application the user could process a
presented to the user as HTML. Only the portion of the response and make a new request using the AJAX
browser page needed to display the results is refreshed. interface faster than when using the HTML interface.
Consider a task consisting of a sequence of operations The total time needed to accomplish the task is the
carried out through an HTML web application. sum of the time needed to download each of the pages or
Accomplishing the task requires loading an initial page, responses plus the cognitive time needed for the user to
and then successively loading pages 1 to n, where n is the view the page or response and make a new request.
number of steps needed to accomplish the task. For an When using a fast network connection such as a local
AJAX application, accomplishing the task requires area network, the download time is typically not readily
loading an initial page, and then successively handling visible to the user. For a moderate speed connection, it
responses 1 to m, where m is the number of steps needed becomes visible only for large results, and for a dialup
to accomplish the task. For the two applications connection, the download time is always of concern. In
discussed in section II above, n=m since both these cases, the value of using asynchronous requests is
implementations provide the same user interface. Define diminished, since the slowness of the communications
the following notation. channel may serialize the responses. Downloading

© 2008 ACADEMY PUBLISHER

JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008 33

multiple responses concurrently over a slow link may information. Thirteen-thousand two-hundred and sixty
actually cause the first of the responses to appear much queries were posed using the production HTML form
more slowly than it would when using synchronous queries, and also posed using the AJAX form queries.
requests, thereby increasing the latency of the user The server logs produced by the Apache web server were
interface. also collected for the appropriate periods. The number of
bytes returned for each query was recorded for the
IV. DATA COLLECTION
HTML query (quantity Pi above) and for the AJAX query
The initial load of the HTML application requires (quantity Ui above). The size of each response does not
42.2KB overhead (15.2KB for the common elements - include the common elements loaded from the client
graphics, CSS, navigation JavaScript, and 27KB for the cache; the effects of caching common elements were
HTML page presenting the form). Thereafter, each studied in [6]. The HTML values ranged from 27KB, a
response file is a complete XHTML page containing the query producing no courses, to 1.9MB, a query listing all
results of the query, the HTML presentation, and the courses for the fall semester. The AJAX response byte
form. The common elements need to be loaded only values ranged from 7.6KB to 1.1MB. A summary of
once if the browser supports caching. these results is shown in Table I.
The initial load of the AJAX application requires TABLE I
99.2KB overhead (15.2KB common elements - graphics,
RESPONSE BYTES SUMMARY
CSS, navigation JavaScript, 27KB for the HTML
presentation and form, and 57KB AJAX JavaScript Response bytes HTML Pi AJAX Ui PI
code). All of these elements need to be loaded only once N 13,260 13,260
if the browser supports caching. This initial load could Min 27,650 7,746 71.99
Max 2,017,914 1,196,618 40.70
be made smaller if the AJAX application were not Mean 129,828 68,234 47.44
reproducing the graphics and look-and-feel of the Median 63,996 28,996 54.69
existing HTML application. After loading the AJAX Total 1,721,523,273 904,776,578 47.44
application, each response is an XML file containing the
query result data and other information produced by the Using White’s definition of performance increase
server application. (PI), the performance increase for bytes transferred gives
a percentage improvement when AJAX is used compared
to HTML. A larger performance increase value is better,
although any positive value represents a performance
increase due to the use of AJAX. A performance
increase of 47% means that the savings achieved by
using AJAX as a percentage of the HTML size is 47%.
The performance increase values for response bytes
transferred are summarized in Table I. The mean
performance increase was 47.44%, and the median was
54.69%. The maximum response size produced a
performance increase of 41%, and the minimal response
size produced a performance increase of 71%.

Fig 4. Data collection for the experiments

All data was collected by querying the production

servers. Perl scripts were written to produce the exact
queries generated by the HTML application and by the
AJAX application (see Figure 4). Note that the server
sees no differences from queries generated by the Perl
Fig 5. Response size PI versus HTML response size (KB)
scripts and by the two applications. The Perl scripts then
collected the responses sent by the server, and recorded The performance increase for response size is
the size of each response and some client-side timing nonlinear in nature, and varies with the size of the HTML

© 2008 ACADEMY PUBLISHER

34 JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008

response. Figure 5 shows a graph of the response size 41%. The predicted Byte Transfer Ratio values level off
performance increase (in percent) versus HTML response at about 55% under this model, giving a predicted
size (in K bytes). The initial download size and the performance increase of 45%.
overhead are not accounted for in this calculation, only In a “real life” use of this application, a typical student
the response size. The smaller responses have greater presents about seven queries to build a semester
performance increases than do the larger responses. The schedule. Using the median response size values from
largest response sizes provide a performance increase of Table I and totaling over seven queries produced the
about 41%. performance increase seen by a typical user, displayed in
A visual evaluation of the graph in Figure 5 indicates Table II.
that it appears to exhibit exponential decrease. To test TABLE II
this observation, the quantity Byte Transfer Ratio is
found by subtracting the performance increase percent TYPICAL USER’S IMPROVEMENT
from 100: Byte Transfer Ratio = 100 – performance 7 queries Bytes
increase. The Byte Transfer Ratio is thus HTML Σ Pi 447,973
AJAX Σ Ui 202,972
Byte Transfer Ratio = (AJAX size/HTML size)*100 PI 54.7%

This represents the reduction achieved by using AJAX H + Σ Pi 491,185

when compared to the HTML application. A Byte A + Σ Ui 304,553
Transfer Ratio of 42% means that the size of the AJAX PI 38.0%
transfer is 42% of the size of the HTML transfer. A
small Byte Transfer Ratio is better; it means the AJAX
A typical user would experience an improvement in
application is performing more efficiently than the
response bytes transferred of almost 55%. If the initial
HTML application. However any value less than 100%
download sizes (H and A) are added in, the actual
represents a reduction in bytes transferred when using
improvement on total bytes transferred for the session,
AJAX.
assuming no cached elements, becomes 38%.

V. SERVER PERFORMANCE

Additional performance gains result from the

reduction in the load placed on the server. The server
load reduction for the AJAX application is due to several
factors. No XSLT processing is required for the AJAX
application. For the HTML process, the number of bytes
handled by the server process is proportional to the sum
of the XML data and the HTML response page, since the
process reads the XML data, processes the XSLT
transform to produce the HTML response page, and the
web server then sends the resulting HTML response page
to the client. For the AJAX process, no XSLT
processing is done; the XML data is simply forwarded to
the client by the web server. This means the AJAX
application results in significantly fewer bytes being
Fig 6. Byte Transfer Ratio versus HTML response size (KB) handled by the server. Fewer bytes also means faster
connection termination, which could increase the number
To determine if the Byte Transfer Ratio is distributed of connections serviced.
exponentially, the 13,260 values Ui/Pi for the application The number of bytes returned for a given query is
were used. Given Pi, an estimate of Ui/Pi is given by the deterministic, and does not vary with the load on the
function β(1- e-λPi). A nonlinear fit to the function β(1- e- servers. To measure the effects of the use of AJAX on
λPi
) was performed using the SAS 9.1 for Windows (SAS the servers (and hence the apparent responsiveness of the
Institute, Cary, NC) NLIN procedure. The SAS NLIN application to the user), the time to service each request
procedure estimates for the parameters β and λ were was recorded from the Apache web server log. An
β=55.68 and λ=0.0264. A Kolomogorov-Smirnov test examination of a small sample of these times collected by
revealed that the predicted distribution was a good fit for two clients showed that they had wide variations due to
the observed distribution. Both the observed and the the exogenous load applied to the servers. To reduce the
predicted Byte Transfer Ratio values (in percent) for the variance of the service times, repetitions of a set of 121
queries are shown in Figure 6, plotted against the HTML queries were performed for both the HTML and the
response size in K bytes. AJAX applications. A summary of the response times in
The actual Byte Transfer Ratio values level off at seconds for the total of 13,260 queries is presented in
about 59%, so the performance increase is limited to Table III.

© 2008 ACADEMY PUBLISHER

JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008 35

The service times summarized in Table III were and there was no correlation between the size of the
statistically tested and determined to be not statistically response and the reception of poor service.
linearly related to the size of the response in bytes. This
means that additional processing is performed on the
servers to prepare the responses to be sent to the client.
TABLE III
RESPONSE SECONDS SUMMARY

Response seconds HTML AJAX

N 13,260 13,260
Min 0.31 0.25
Max 37.58 34.42
Mean 1.53 1.29
Median 0.89 0.73
Std Dev 2.44 2.26
Total 20,252.32 17,090.15

Some of the queries were presented to the server using

HTTP/1.0, with one request and response per web server
connection. Some of the queries were presented to the
web server using HTTP/1.1 with “keep-alive”, which
allowed several request/response pairs per web server Fig 7. Response time for each of 110 trials of the same query
connection. There were no statistically significant Table IV summarizes the response times for four
differences between the sets of data collected using these groups of requests. The All group includes all queries.
two methods. For this application, the service time The 99% group includes 99% of the queries; it excludes
required to generate the data for the response dominates queries with the longest 1% of response times.
the total request service time, and there was no Correspondingly, the 95% group excludes the longest
significant savings to the user when maintaining an open 5%, and the 90% group excludes the longest 10%. The
server connection to service sequential requests, as service values for the “best” 95% of all requests are
proposed by Windley in [9] for “Comet” AJAX summarized in the 95% column in Table IV. Note the
applications to provide low latency data to AJAX client improvement of the coefficient of variation (CV) values
applications. when moving from the “all” group down to the 90%
As previously mentioned, all data was collected by group. For HTML service, the CV decreases from 160 to
querying the production servers. The production HTML
application averaged 180 page views per hour (3 per TABLE IV
minute) over the months of October, November, and RESPONSE TIMES IN SECONDS
December of 2006; the peak day averaged 676 page
views per hour (over 11 per minute). The queries for this HTML All 99% 95% 90%
study were performed sequentially, but response times N 13,260 13,129 12,597 11,935
suffered due to contention for server resources from the Min 0.31 0.31 0.31 0.31
ongoing production demands on the servers, including
Max 37.58 15.38 4.36 2.65
the queries from other users. The set of queries reported
Mean 1.53 1.34 1.10 0.98
represents a sample of “real life” responses.
Figure 7 graphs the response time in seconds for 110 Median 0.89 0.87 0.82 0.75
separate trials for the AJAX response to the “List all Std Dev 2.44 1.53 0.82 0.64
courses” request. This request returned 1,196,681 bytes. CV 159.7 114.1 74.0 65.0
The mean response time for this query, shown as a Total 20,252 17,618 13,872 11,685
dashed line in Figure 7, was 12.69 seconds, and had a % CV Improvement 28.6% 53.7% 59.3%
standard deviation of 2.59 seconds. The minimum
response time for this query was 10.62 seconds, and the
AJAX All 99% 95% 90%
maximum response time was 31.02 seconds. The peak
N 13,260 13,128 12,598 11,935
value is truncated in Figure 7 for economy of
presentation, otherwise the graph would need to be Min 0.25 0.25 0.25 0.25
almost twice as high. The random nature of the poor Max 34.42 11.26 3.48 2.19
response times is evident in this graph. Mean 1.29 1.11 0.92 0.82
While the large portion of requests received Median 0.73 0.71 0.65 0.60
reasonable response service, a few of the requests Std Dev 2.26 1.24 0.67 0.59
received very bad response service, just as in “real life”.
CV 175.2 111.6 73.4 65.9
These poor response times were seemingly random - not
Total 17,090 14,541 11,545 9,775
predictable, not repeatable, there was no correlation
between poor HTML service and poor AJAX service, % CV Improvement 36.3% 58.1% 62.4%

© 2008 ACADEMY PUBLISHER

36 JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008

65, an improvement of 59%. Similarly, the CV for Calculating the performance increase from the means
AJAX service improves from 175 to 66, an improvement of the 95% groups in Table IV (that is, the improvement
of 62%. of the mean response times of the two 95% level groups)
Figure 8 illustrates the reduction in size of the range gives an improvement of 16.8%. Calculating the
of the values as well as the reduction of the standard performance increase from the means in Table IV (that is,
deviation for each of the samples shown in Table IV. the improvement of the mean response times of all of the
The vertical scale has been made nonlinear to more data) gives an improvement of 15.6%.
clearly show the areas of interest in the plots. The size of
each box represents the range of values from the TABLE V
minimum to +1 standard deviation above the mean. The
median value is the horizontal line in each box, and the TYPICAL USER’S IMPROVEMENT
maximum value is indicated by the T line. Note the 7 queries Response bytes Response secs
reduction in variation when moving from the All group HTML 447,973 6.209
to the 90% group for both the HTML and the AJAX data. AJAX 202,972 5.117
PI 54.7% 17.6%

95% HTML 5.74

95% AJAX 4.55
PI 20.7%

In a “real life” use of this application, a typical student

presents seven queries to build a semester schedule.
Using the median values from Tables I, III and IV and
totaling over seven queries produces Table V. A typical
user would experience an improvement in response bytes
transferred of about 55%, and an improvement in service
time of almost 21%.
VI. CONTENTION
An additional experimental procedure was developed
to estimate the contention at the web server due to the
Fig 8. Box plot of values from Table IV. time needed for the application to serialize the data base
queries. The 13,260 queries (see Tables I-V) used the
An example drawn from Table IV shows that 95% of existing production application on the server. This
HTML requests received service in 4.36 seconds or less. application uses a process on the web server to serialize
In the longest 5%, one unfortunate response received a the data base queries from all users of the application to
service time nine times as large. For AJAX requests, send over the application’s database connector to the data
95% received service in 3.48 seconds or less, while the base server. All requests from the web application were
longest AJAX request received a service time ten times serialized and transmitted over this connector to the data
as large. The averages for the 95% group give better base server. The contention test web application was
estimates of expected service times for typical users of modified to use a separate database connector for the data
the application than do the averages for the ALL group. base queries. This eliminated the contention for the
Using White’s definition of performance increase, the connector from other users’ queries, and enabled the
mean of the performance increases for response size is development of an estimate of the impact of the
56%. This is found by computing the performance contention on the server’s response times. Note that the
increase for each query (pairing the HTML and the queries sent to the test application were serialized by the
AJAX responses for that query) and then calculating the test software; no contention occurred due to test queries.
mean of these values. Since the response size is The results from this test, however, do not apply to the
deterministic, the performance increase for response size responses seen by a typical user of this application, since
for a given query remains the same for every repeat of access to the test system is not public.
the query. Table VI summarizes the response time results of
Determining the performance increase for response 1968 queries, divided into four groups – HTML and
time is more complicated due to the randomness in the AJAX combined, and HTML and AJAX separate. The
data. Computing the performance increase for response combined queries used the production process while the
time for each query and then calculating the mean of separate queries used the test process and its separate
these values gives an improvement of 2.4%. However, database connector. The number of bytes returned was
for about 4% of these queries, the AJAX response time the same for corresponding HTML and AJAX queries
was larger than the HTML response time. Indeed, one regardless of which database connector was used, and is
query resulted in an AJAX performance “increase” of not shown in Table VI. Comparing the response times of
-7135%. the combined and the separate groups shows that the

© 2008 ACADEMY PUBLISHER

 JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008 37

average server response time declined for this test for efficient database query process is more likely to reduce
both the HTML and AJAX queries. The mean HTML the wait time for the server query process for all users
response times declined by an average of 14.15%, and than would the use of the AJAX application.
the AJAX times declined an average of 2.7%. When the client-server bandwidth needs to be
TABLE VI
improved, AJAX can be effectively utilized. However,
AJAX can have less impact on server utilization than on
RESPONSE TIMES FOR TEST SYSTEM the client-server bandwidth.
Combined Separate
Response secs HTML AJAX HTML AJAX ACKNOWLEDGMENT
N 492 492 492 492
Min 0.38 0.30 0.33 0.28 Dan Chase assisted in the collection of data for this
Max 40.42 28.99 27.64 28.39 work.
Mean 2.12 1.47 1.82 1.43 REFERENCES
Median 1.04 0.88 1.04 0.79
Std 4.40 2.34 2.96 2.17
[1] L. Paulson, “Building rich web applications with AJAX”,
CV 207.57 159.51 162.19 151.61 IEEE Computer, 38(10), 2005, 14-17.
Total 1042.35 721.01 897.64 704.84 [2] Crane, Pascarello, James, Ajax in Action, Manning
However, the variability in the response times Publishing Company, Greenwich, CT, 2005.
[3] AJAX Patterns, “Ajax Examples”, retrieved August,
remained large, as evidenced by the standard deviation
2007, http://ajaxpatterns.org/Examples.
and CV values in Table VI. Eliminating the web server’s [4] C. Merrill, "Using AJAX to Improve the Bandwidth
query marshaling time confirms that the randomness in Performance of Web Applications", Web
response times is primarily due to contention for the data Performance.com, January 2006
base server. [5] A. White, “Measuring the Benefits of Ajax”, retrieved
March, 2006,
VII. CONCLUSIONS http://www.developer.com/xml/article.php/3554271.
[6] C. Smullen, S. Smullen, “Modelling AJAX Application
The savings in transmission time between the server Performance”, 524-074, Web Technologies, Applications,
and Services 2006, ed. J.T. Yao, ACTA Press, Calgary,
and client are significant due to the average 56%
2006.
reduction in the bytes making up a response. AJAX can [7] C. Smullen, S.Smullen, "AJAX Application Server
significantly reduce the bandwidth required for the client Performance", Proceedings of the IEEE SoutheastCon
to receive a response, or can improve the response of the 2007 (CH37882), March 22-25, 2007, Richmond,
application as perceived by the user by presenting a Virginia, pp. 154-158.
response faster than the traditional HTML application. [8] Sarissa, http://sarissa.sourceforge.net/ retrieved March
However, the reduction in time that the server spends 2005. The Sarissa project page is found at
generating a query (16%) indicates that AJAX is less http://sourceforge.net/projects/sarissa.
useful as a server productivity tool. While eliminating [9] P. Windley, “Comet: Beyond AJAX”, retrieved
the query marshaling time does improve the average December, 2006,
http://www.irishdev.com/NewsArticle.aspx?id=2173.
response time, it does not reduce the variability in the
response times. In the case of this application, a more

© 2008 ACADEMY PUBLISHER

View publication stats