Thursday, February 20, 2014

What chrome browser developer console can do for performance testing

     As professionals on performance testing, we always strive to
  1. find the capacity of a web site and
  2. pinpoint the bottleneck. 
    While we can find capacity of a web site by emulating enough virtual clients on a test platform,  it's less obvious how to find the bottleneck - especially when you don't have access to internals of a web site.  A web infrastructure typically consists of multiple components:
  • web servers, 
  • application servers, 
  • database servers. 
    Being able to identify the bottleneck will help a lot when it comes to improving the performance of the system or making decision on which hardware resource to add.

     In this blog, we give an example that shows we may get some idea on performance bottleneck using a tool that is surprisingly simple and common:  the developer console on chrome browser.  I am sure there are other such tools/plugins that can help as well.  To use developer console on chrome browser, all you need to do is to right click and select "Inspect Element" in the popup menu,  you can then open the "Network" tab.  Here is something you may see:

    Recently I did a test on a web site hosted in the cloud and it consists of a web server and a database  server.  Here are some of statistics on the response times of various pages collected by developer console.  The response time is defined as the time between sending a HTTP request and receiving the entire HTTP response.
web page
response time
/  (main page)

    As we can observe, the 3 HTTP requests for "/projects/abc/filter" with different parameters took incrementally more time with the increasing complexity on the query.   These  HTTP requests are generated by Ajax call and the responses are pretty simple: just a few blocks of HTML code.

<div class='results'>  
      <div class='tags'>Tags:   
           <a href="/projects/abc/subjects/52">cars</a>  
           <a href="/projects/bc/subjects/82">Flowers</a>  

    The processing done by web server (Apache/Ubuntu in this case) is pretty light,  judged by the simple structure, the time spent on web server part could be as low as a few milliseconds, so most of the time may have been spent on database operations.  Before we conclude that the bottleneck in this case is the database,  someone may ask,  what about round trip time?  Roundtrip time can potentially be high and varying a lot, making it harder to draw a conclusion.

  The round trip time can best be estimated by pinging the site. Here is a simple example.
 PING ( 56(84) bytes of data.  
 64 bytes from ( icmp_req=1 ttl=48 time=85.3 ms  
 64 bytes from ( icmp_req=2 ttl=48 time=80.7 ms  
 64 bytes from ( icmp_req=3 ttl=48 time=79.4 ms  

    However, it doesn't work all the time since some sites (including the one we were testing) has turned off the ICMP echo reply so ping will simply timeout and not give any information.   Developer console has another piece of information that can help: TCP connection time.   In the above snapshot, the yellow popup window has a line "Connecting", that's for TCP connection time.

    In my experience, this can be a good approximation on the roundtrip time (in theory, it also includes the time an OS TCP/IP stack spent on creating the connection and sending the TCP SYNACK, but the extra time is typically less than a ms).   Back to our test, the roundtrip times are typically around 50ms.  So we know the roundtrip time doesn't affect the total response time much and our conclusion will stand that the database side needs some optimization.

    Developer tool is such a great companion for professional performance testers, I hope you will like it too.

No comments:

Post a Comment