Showing posts with label response time. Show all posts
Showing posts with label response time. Show all posts

Wednesday, February 25, 2009

Safari - Performance

Apple came out with its new browser Safari 4 Beta and as a performance guys, I found something really interesting. Apple claims "Safari’s Nitro Engine executes JavaScript up to 30 times faster than Internet Explorer 7 and more than 3 times faster than Firefox 3. "

Wow! 

As I said earlier here, most of performance testing tools doesn't have ability to report end user response time and one of the reason being different Javascript engine used by different browser vendor.

For more information about Safari and its performance, check here and here

As usual, comments are always welcome.

-Thiru

Thursday, January 15, 2009

End User Response Time Vs Tool Response Time

In olden days browser is more of display tool and for heavy client side processing, thick clients were used. As time and technology evolved, things have changed and current browser itself is more like think client. As the client side logic becoming heavy, obviously client side processing time has to be added to server side response time to get end user response time.

The Truth about performance testing tool

In modern day internet/web application, response time can be computed as follows

Response time = server side response time + network delay + client side processing time + rendering time

Where as our load testing tools, computes response time as follows.

Response time = server side response time + network delay.

Since client side logic is heavy in modern day web/internet application, most of the tools available today are really missing out the significant portion in response time.

Adding fuel to fire (Java Script Engine)

Because Java Script is so important to the web today, no one can even imagine a web application without java script. A JavaScript engine (also known as JavaScript interpreter or JavaScript implementation) is an interpreter that interprets JavaScript source code and executes the script accordingly in client’s browser. In real, java script execution time by Java Script Engine is also added to end user response time. To name few Spider monkey, V8 are couple of open source java script engine.

Even if some tools has ability (like Loadrunner click & script), it is very limited to a particular browser and particular java script engine.

More Fuel

Even if a tool is able to makeup the java script's response time, calculating full response time by tool has exception. PLUGINS. It is practically impossible for a tool vendor to work with all plugins available. Java and flash are the commonly used plugins in lot of web sites.

Just want to quote an example

In one of my previous client environment, single user test for a particular page click takes around 50 sec, whereas the loadrunner @ 1000 user load reported the max response time as 10 sec. After seeing the result, client has called in for a meeting and they demonstrated his portion and proved that in real, that particular page takes much longer time to view. To stick to our result, we have done a sniffing of that request using network sniffer and showed that client side JS doing some nasty calculation is the culprit not the server. Also we explained them that, whatever loadrunner gives are the server side response time not the end user response time.

So sad

Even if performance testing tool vendors wants to include client side response time, it is very difficult for them as whole lot of java script engine out in market with various market shares.

Even tough for some, it is hard to believe that server side response time and end user response time are very different, we have to accept(as it is fact).