- find the capacity of a web site and
- pinpoint the bottleneck.
- web servers,
- application servers,
- database servers.
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)
|
0.31s
|
/projects/abc
|
4.97s
|
/projects/abc/filter?kind=45&actors=47&means=1&page=0
|
1.91s
|
/projects/abc/filter?kind=45&actors=46,47&means=1&page=0
|
2.06s
|
/projects/abc/filter?kind=45&actors=46,47,48&means=1&page=0
|
2.68s
|
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>
</div>
</div>
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 www.yahoo.com
PING ds-any-fp3-real.wa1.b.yahoo.com (98.138.253.109) 56(84) bytes of data.
64 bytes from ir1.fp.vip.ne1.yahoo.com (98.138.253.109): icmp_req=1 ttl=48 time=85.3 ms
64 bytes from ir1.fp.vip.ne1.yahoo.com (98.138.253.109): icmp_req=2 ttl=48 time=80.7 ms
64 bytes from ir1.fp.vip.ne1.yahoo.com (98.138.253.109): 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