Home     RSSRSS

Archives: Performance Center

Compression,Decompression,Mobile Performance and LoadRunner

February 4, 2013 by kiranbadi1991 | 2 Comments | Filed in Decompression, Development, LoadRunner, Performance Center, Performance Engineering, Scripting, SilkPerformer

Recently I inherited some of the  LR scripts from one of my colleagues,it was all about building the json calls for stressing the backend spring security framework which was first layer of entry into the mobile infrastructure.Those scripts were simple scripts  built using the custom request with json string as a body part.One of the things that really surprised me as part of this effort was that web custom request in itself was taking close to 100ms to 300ms to do decompression of the server response during load testing.

Okay first let me give you some background,servers were configured to send the response compressed in gzip format with content encoding header as gzip.The functionality under scope had SLA of 1 sec max and quite a few functionality in scope also had SLA that was less than 500ms.Quite a challenging SLA’s I would say.But again these functionality were supposed to be accessed over the mobile device,so probably less the response time better it is for users.

Most of the response coming from the server for all functionality was served as chunked bytes,so what it means is that server sends initially some bytes as response in compressed gzip format,LR decompresses  those bytes in 5 to 10ms and then again server sends next range of bytes as chunked gzip response and then again LR will spend close to 5 to 10ms to decompress those bytes and like wise the process continues till we have final set of bytes.All these process happens in the single connection and connection never closes with the server.In case if you do have some server response validation in place, then expect that it will add another 10ms to do that validation.

Now I have measured all these times in the single iteration of vugen,these times increase exponentially when we are running the Load Test in controller or PC and this overhead of decoding the gzip content becomes a quite an issue when response time SLA are in ms.

Here is how it looks when you see the behavior in LR Vugen with decompression on in the script.You can see that it takes 5ms to decode the 154 bytes of response.Now imagine the normal webpage will have size of 2mb of data gzipped,so you can see the impact of this decoding  when size of page increase specially when response is coming as chunked bytes with no fixed content length from the server.



I think HP LR team might also be aware of this behavior and probably that the reason as why they might have come up with function to disable this.Use Web set option with decode content flag turned off if you are running the scripts which do not require validation and has response time SLA’s in ms.The drawback of disabling this feature is that all your correlation and other checks for server response will fail since server response will show up as binary content like below.



I would suggest you to disable this feature if you can and do the response validation by using the other techniques like verifying server logs etc.By disabling this you will gain close to 15 to 20% reduction in response time reported by LR.

Is this expected behavior of LoadRunner ?, I think they have to do this,unless they decode the response, none of the other function like web reg save param or web reg find will work and these functions are core functions of LoadRunner.Probably the right way is that LR should not add these decompression timing in their transaction markers.These timing really pollute the results specially for web applications or probably they can increase the speed of this decompression library what they are using in LoadRunner.

Tags: , , , ,

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: , ,

5 Reasons as why HTTP Debugging tools should not be used for preparing Load Testing Scripts.

January 20, 2012 by kiranbadi1991 | Comments Off on 5 Reasons as why HTTP Debugging tools should not be used for preparing Load Testing Scripts. | Filed in LoadRunner, Performance Center, Performance Engineering, Performance Test Tools, Scripting

In Recent times I have seen a kind of trend where in performance testers use tools like fiddler/yslow/httpwatch for scripting purpose in spite of having fully licensed version of the LoadRunner or other performance tools.I find this approach to be somewhat immature and prone to many errors if done by someone who do not understand performance engineering concepts or someone who does not understand the semantics of the web communication. I also find this kind of trend bit disturbing and harmful to the load testing industry for many reasons. I will list down some of the reasons why I feel this is a very bad idea and why one should not take this way for scripting purpose for preparing their load testing scripts.

I have encountered many times in my career where in the application in spite of working with supported protocol do not get recorded by the load testing tool. On further analysis of the issue, I did come across certain findings that either the setting which we use for recording the applications were incorrect or we were recording in the unsupported environment or it was just that firewall or DEP or some antivirus software setting were blocking the recording. So for sake of this post I am not writing here anything on as how I troubleshoot recording problems but will surely take some time later on to write on this as well. It’s interesting topic and deserves a separate post. So let me go back to original purpose of this post and write some of my thoughts why one should not use fiddler or any other HTTP Debugging tool to script a load testing script,

1. Tools like Fiddler/Yslow are the http debugging tools and not the scripting tools. They show http requests as resources are downloaded and interpreted by the browsers. Since page contains many resources, it becomes hard to tag these resources to the main request unless you are page author. Since the requests captured by these tools are context less and are not orderly distributed so I feel it cannot be used for scripting purpose and so they cannot replace the load testing tools.

2. Building the post requests from these tools is somewhat harder compare to get requests though not completely impossible depending upon the type and complexities of applications.

3. Since requests are displayed context less or in uneven order, correlation or capturing dynamic values is somewhat hard and prone to lot of errors resulting in many hours being wasted.

4. These types of tools follow the web standards and to know and understand information generated by these tools in real sense one needs to know and understand various RFC’s involved in the web communication. I have seen most of the Performance testers are unaware of these standards.At least this is my observation. It has taken years for me to understand as how web communicates.

5. From project finance prospective, we should not forget that we are paying five to six figure amounts to the licensed load testing tool vendors for using their product, so it makes more sense to ask them to fix these recording issues rather than using HTTP Debugging tools for scripting purpose. Also it looks bit odd when we use Open source HTTP Debugging tools to script when we have licensed version of the load testing tool. If you have program management office or PMO, who are auditing your projects, then they are surely going to scream on you for wasting so much of amount on load testing tools and not using it to their full potentials or capabilities.

Finally I would like to mention here is that this post is more about using right tools for the right job. HTTP Debugging tools are for debugging the web http communication, so I suggest let’s use these tools for debugging and load testing tools for preparing load testing scripts. In case for any reasons, if you are unable to record the script in spite of having supported protocol, then by all means you have all the rights to shout at the vendor and get the issue resolved.

Tags: ,