Home     RSSRSS

Archives: Performance Test Tools

Performance Testing Web based Ajax Applications–Then Read this

June 23, 2012 by kiranbadi1991 | 2 Comments | Filed in Browser, Development, LoadRunner, Others, Performance Center, Performance Engineering, Performance Test Tools, Scripting, SilkPerformer, Testing

From past couple of days,lot of people have asked me about Ajax,Ajax protocol and how to Load Test Ajaxified Applications. So I though let me write a short code and try explain my thoughts about this. Ajax is often used in the web site to do quick and short interaction with servers for implementing some of the if then condition to implement some requirement.Ajax helps a lot in bringing some interactivity or I can say it creates VOW experience.Of course I am not the hard core front end engineer ,but yes having written couple  of lines of CSS/HTML/Javascript, I can visualize and make a sense as how to write the front end code which brings some interactivity to the site.

For the sake of this post, I have used Jquery library which has rich methods for making Ajax calls.It also has excellent methods of interacting with CSS and HTML markup elements.With Jquery we can easily write the call back function and write the response data to the DOM on the fly based on some conditions.Few drawbacks Which I noticed using  Jquery library is that it makes you lazy (If you really want to become good front end engineer, then having good gasp of Raw javascript is must) and just for implementing one or 2 functionality , I have to import 10 k lines of code.But again with Jquery benefits outweighs the risks.

Implementation of Ajax with Jquery looks something like below

        var ae = $(“#idtxt1”).val();
        var ap= $(“#idtxt2”).val();
        var request = $.ajax({  
            url: “TestAjax.do”,
            type: “POST”,
            data: {
            cache: false,
            success:function (data){
//                $(“#idspan”).append(data);
                if(data == “Success”){ //redirect…
                      window.location = “/mysite/mypage.php”;
                } else { //report failure…

            error: function(data) {


The granular level of details of Jquery Ajax function can be found here. So you might be thinking as why I have written this piece of code when it’s already available. This post is not about Jquery or how to use Jquery, this post is about understanding Ajax and how they are implemented and based on that coming up with proper solution for load testing Ajax based web applications.

If you look at the above code closely,you can observe that it does post request on the form submit event.As soon as user clicks on the submit button it does the call to the backend program.This is how browsers operate.Browsers bring interactivity to the site using event driven methods.This understanding is the key to know as how Ajax calls are made, every Ajax call is associated with some user driven event on the HTML Element. Events could be on Click, on Submit, on Hover,onMousein,onMouseOut,Focus in,Focus out,onKeyPressup and onKeyPressdown.These are some of the events which are associated with the HTML Elements and Javascript is used bring some interactivity to the site on occurrence of the these events.So every Ajax call has some event associated with it.Please note that there are many many events associated with each HTML element and complete reference of those can be found ECMA Javascript Guide or Web Standards document.

So continuing further, the above code makes the Ajax post call to TestAjax. do function which resides on the backend server.In above Ajax function call I am collecting value of 2 text fields name #idtxt1 and #idtxt 2 and passing those values as post body request to my backend J2ee program.Most of the Ajax calls irrespective of the library used do these things in the similar way(almost 99.99% of time),they capture the user inputs with Javascript methods and then post the data to the backend program which resides on some application servers.The program which resides on the backend servers communicates to the Ajax call whether the request has passed or succeeded.If the request succeeds , for example in above code if my backend program sends me the data as “success”, I redirect the request to mypage.php and if requests fails, I write some error text to the HTML  page within Span Element.

The browsers developers tools also helps in understanding the way Ajax often works,


If you capture the network trace with Browser’s developer’s tool, the trace would look something like above, in the trace you are clearly see that Initiator of the call was  XMLHttpRequest. This is nothing but the core method which implements Ajax calls in the browsers.Since the above request was of type GET, values were appended to the url of the request and send to the backend program.In addition to this these tools bar also give lot of other information like http status code, which event initiated the request etc.However I will not suggest you to measure the response time of Ajax calls with these tools as I believe they somewhat give incomplete picture of response time.

The response data received from the server can also be viewed via browser developer’s tool and in my case it was looking some thing like below,


This response data(“Username not available”) is later appended to the page elements which is viewed the end users.

So coming back to original purpose of this post, I keep hearing from various Performance Engineers that existing Web Http protocol is insufficient in testing Ajax based web applications, now having implemented real time Ajax with fat datasets, I believe there isn’t much challenge to load test Ajax based applications.We just need to keep some key things in mind while working with Ajax based applications,

  • Understand the functionality of your application from technical prospective.
  • Ask developers explicitly, which functionality in the application is using Ajax call, is the Ajax call synchronous or Asynchronous.With Synchronous Calls,one cannot proceed unless he receive the data from the server for his Ajax call and with Asynchronous calls, one can work on the other parts of the page(Technically with Async Calls, browser need not wait for server response to build DOM Tree and with Sync calls, it has to wait for server response).
  • If you believe some events for your applications are not getting recorded via regular HTTP protocol, then probably you are not triggering the Ajax call at all.Remember to trigger Ajax call, you need to Trigger an event on the html element and it could be that you need to tab out of the element or bring focus in that element etc etc.Ask your developer as how to trigger a Ajax call for the business process under scope.
  • If you believe that you are not able to record Ajax call, then probably your Ajax request is cached.Ajax calls are heavily cached by browsers since they contain all JS/CSS files in them.Clear browser cache/cookies etc etc and Try again.Use Developer tools bars to debug such cases,ensure that you get 200 status for all your resources.
  • Ajax calls irrespective of libraries or technology uses regular GET/POST types which is nothing but http calls.Http calls should and must be recorded if tool claims to support HTTP Protocol.
  • If you see some unique values getting generated at the client side and these values are not seen in the server response, don’t get scared or nervous, they might be Unix style timestamp or Microsoft tick timestamp(However If you get Tick, you have solid reason to worry and it could be your pure good luck if your application is not using complete power of Tick.If it heavily uses Tick, then probably you need to go temple and prey God.You will surely require his blessing.Most of the current set of tools don’t go beyond Unix style timestamps and Tick is much more powerful timestamp format than Unix style timestamp).These values are generated by JS library in order to force browser not to cache the key JS files.However lot depends on the headers as well.
  • Thick client web based applications often uses chained JS calls to build different parts of the page, All you need to do in these cases is to ensure that you follow the right steps, trigger the events which chains many events during recording and then do your regular steps.
  • Remember for Load Testing Ajax based application still the goal would be capture the network traffic which goes out of the application to the server and stress the server for those calls.If your Ajax calls are slow, then it gives an impression that front end is taking more time,most often it is never true.Spinning wheel which keeps spinning for minute or seconds indicates server bottleneck and not client side bottlenecks.
  • Remember client side performance measurement metrics/techniques are different than Server side performance measurement/techniques.They require different skillsets and tools.Just having lot of Ajax calls do not necessarily mean that you have client side performance issues.However it does mean that you do lot of DOM Work and always browser needs to keep working or guessing so as to where and how much some space for response data.So repainting and refills of DOM happens quite often.

So finally you must be wondering if Ajax can be done with regular http protocol, then why are companies like HP coming up with new Ajax based protocol etc for Load Testing.

Answer is simple, they want to save some time for scripting and time is money in corporate world.

How much time it saves ?

Again I cannot say as I have never used these protocols myself.But I have some doubt whether they can successfully emulate the calls for all events.There are lot many ways to trigger Ajax calls.If you use Ajax protocol without understanding the fundamentals of Ajax, then I would say probably its incorrect way of doing the Job.There exists a high risk that your text checks will always succeed not matter what as most tools do not have JS Engine or HTML Parser in them, so they have limited ability to read or write to the HTML document.With Ajax most of the time error validation is done without browser refresh based on some conditions.So you have extra cautious here.

If you still believe we cannot test Ajax based application with regular http protocol, then I would like to hear from you about such cases and would appreciate your feedback with some sample test use case.

Technorati Tags: ,,

Tags: , ,

Sessions, Client Side Javascript and Correlation

June 8, 2012 by kiranbadi1991 | Comments Off on Sessions, Client Side Javascript and Correlation | Filed in Browser, Development, Environment, LoadRunner, Performance Engineering, Performance Test Tools, SilkPerformer

Recently I one of my good friend asked me a question ” How do I correlate the session id information which is created via javascript with LoadRunner”

Well this was an interesting question and of course he was not the first one to ask about this, there are lot many people who had asked this question in various online forums like LinkedIn etc.So I thought let me write some of my thoughts on this,

Http protocol as known today technically is the stateless protocol.It means that it cannot distinguish between the first time visitor or a regular visitors.It just forgets the client as soon as request is serviced and this behavior of the HTTP creates the need for maintaining the session information.This is reason as why session generation and maintenance is handled by the programming languages.

Session management with http is normally done by using below techniques

URL Rewriting

With this method of session handling, session ids are often appended to the query string of the url and the query string looks something like below,


Depending on the way we design the application, session information can pass as query string parameters namely in key/value or name/value format and this applies even to session ids.Also at times this method is often used whenever client do not accept cookies for some reason.In fact some servers like web logic etc automatically switches the session handling to this method once they detect that client is not accepting cookies from the server.

URL Rewriting often  leads to ugly urls  so at times these url’s are hidden from the client and replaced by good and short looking url’s.This trick is done by server side modules which can rewrite the urls on the fly(Apache mod rewrite is one such example).The best way to identify if your application uses this method of session handling is to block all cookies via browser and test it.Also there exists some restriction on the length of the url with regard to some browsers like IE.IE cannot take length of the url beyond 2k bytes.


Also using this method at times could lead to security hole as referrer tag are leaked if one navigates in the via same browser window.

Hidden fields

In this method of session handling, extra form fields are sent to the client and these extra form fields always hidden from the client.The hidden fields look something like,

<input type=’hidden’ name=’id’ value=’a’/>

Hidden fields are also used to maintain the page information across the pages and is one of the frequently used method  to maintain session information.The good thing of this method is that url’s remains short and large data can be passed over the server for processing.In addition to session information, hidden fields can also be used to persists the client entered data across the pages.


I feel this is simplest way to maintain the session information and definitely better than url rewriting and hidden fields.Most application as soon as they receive first request, server drop the cookies on the client computer and later on for every subsequent request , they check for its existence in client requests with regard to  further communication.So if we as performance engineer comment out these cookies, then obviously we are asking application to do more work and is definitely a wrong load model as well.Cookies are never commented out in real world scenario and should not be commented out during load testing as well.

HttpSession Objects

These are objects which are created on the server side to store session information.These session objects are never passed on the client.However there might be cases where unique identifier namely jsessionid is appended to the url and send across to the client,in case client do not accept cookies.In this method session is stored in the memory and if the session object is too large, then it gets serialized to the file system or to some disk.Personally I have seen good performance with this method of session handling whenever the user base is small.How ever storing session in the httpsession objects could lead to heavy resources consumption given that sessions cannot moved outside the servers.In other words, application using this method of session handling cannot effectively use  server farms or web gardens as sessions are inproc. Also using this method leads to inefficient usage of load balancers.

Now having discussed some basics on sessions,so where does client side javascript fit in all these ?

Storing or accessing the session via javascript is all big security hole. I don’t recollect even a single instance where javascript was used to maintain sessions for any of my projects.So I doubt if any one uses Javascript to create session or store session information.

So with javascript can we create or access the sessions or session ids ?

I would say yes.Javascript provides rich set of methods to access url’s/cookies/hidden fields and with Ajax , we can definitely create and maintain the session information with javascript.However interesting point here is that what if client turns off javascript in their browsers ? 

Knowing  these risks, do you still believe that people are going to use Javascript to store session information ?

If yes, then probably I need to write another post on how to get around these type of cases given that no load generating tool existing in the market today can execute or capture javascript events correctly as done by the browsers in real sense.

Tags: , ,

IE 9 Browser Network Capture Tool – Not a reliable Network Capture Tool to measure Latency.

February 14, 2012 by kiranbadi1991 | Comments Off on IE 9 Browser Network Capture Tool – Not a reliable Network Capture Tool to measure Latency. | Filed in Browser, Environment, Performance Engineering, Performance Test Tools, Testing

Recently one of the business executive from Catchpoint posted the link in Performance Specialist list in LinkedIn about the potential issue with IE Browser network capture tools where in network capture tool in IE was showing high response time for one of resource when in fact the response time for that resource was in fraction of milliseconds.I found this case very interesting given that given that I have seen lot many performance Engineers and Users using these tools to identify the performance issues. Catch point had made its point very clear, that there are certain cases where in the browser network capture tools do not show us the correct network capture time and the time shown by these tools are impacted by elements of the page.

Given that they had also provided with the test case as how to reproduce this issue,I thought that let me try and see if I can reproduce the issue, so I pulled out their script and loaded it in my Dreamweaver to check this.I was curious to know and understand as what factors of the page were responsible for this abnormal behavior.

I made some changes to the script and pointed the IFrame source to my local Test PHP page hosted on my local Apache server.The point of making this change was to ensure that there is no actual network issues impacting the test case.In addition to this I changed the loop frequency in order to check at what level of DOM manipulation will this issue surface and has major impact on the network capture feature of the browsers.

addDomLoadEvent(function() {
   var title = document.getElementById('title');
       var span;
      for(var i = 0; i <= 1000; i++) {
        span = document.createElement('span');
        span.innerHTML = i;

The above piece of code is taken from Catch Point’s test case and only changes I made was to change value of the loop i.e, I ensure that its creating 10,20,50,1000,5000 and 10000 span elements on the fly and they are aligned inline without styles applied to it.After making changes, I ensured that I am taking the network capture with browser’s developers tools for IE9 ,Firefox 9,Chrome 15, and Safari 5.1.

For Creating 10 Span elements, response time reported by IE Capture tools is 32ms.

IE 10

For Creating 20 Span elements, response time reported by IE Capture tools is 31ms.

IE 20

For Creating 100 Span elements, response time reported by IE Capture tools is 46ms.

IE 100

For Creating 1000 Span elements,response time reported by IE Capture tools is 250ms.

IE 1000

For Creating 5000 Span elements,response time reported by IE Capture tools is 820ms.

IE 5000

For Creating 10000 Span elements,response time reported by IE Capture tools is 1.66 sec.

IE 10000

As you see, more the span elements we create ,more the Iframe’s response time. Since the test case was executed in the local environment with absolutely nothing in network to download, we would have expected the response time of IFrame to be same in all cases.Unfortunately it was not.So I think its fair to conclude that IE 9 network capture tool cannot be used to measure the response time at least for sure iframe elements and possibly for those elements which generate the network requests in the heavily DOM operated environments.

I would like to also add that this test case is not about writing perfect javascript but more of knowing and understanding whether Browser’s capture tools are in fact independent of its rendering and parsing architecture.Finally with this test case we can conclude that at least in IE 9, browser’s network capture tool do depend on its rendering and parsing architecture which at times might give users a incorrect picture of network latency.

Hope some one from Microsoft take a note of this behavior and fix this behavior.

In addition to this there are also many other interesting findings which I came across, maybe sometimes later I will write a note on that in another post.

Finally thanks to Catchpoint for highlighting this issue.

Technorati Tags: ,,

Tags: ,