Basic Web Performance Part 5

As we progress on our journey to performance test our web application. I think it would be appropriate to introduce few key terminology we use in our performance testing.It is important to know what are expectations from our performance testing and certain do and don't . so let me get started as i am not going to explain those terms here you might have to figure out yourself :)
Key Terminology

•  Ramp Up/Ramp down
•  Users/Threads
• Iterations
• Through put
• WorkLoad/Business Flow
• Request/Response
• Load/Stress

Why Do Performance testing

1. Assessing release readiness
2. Assessing infrastructure adequacy
3. Assessing software performacne adequacy
4. Collecting metrics for Performance Tuning

Do and Don't

There are certain do and donts before you perform the performance test.These are again the guideline and all of them might not be applicable.

Do

• Suitable time to Load test when all the parameters like network , user access, application access are under control.
• Define the performance metrics , accepted level or SLA and goals.
• Know the objective of test.
• Know the Application Under Test architecture and details like protocol supported , cookies manages etc.
• Know the Workload Scenarios and peak and normal usage time before the test.
• Use the meaningful test scenario to construct Test Plan which is real life .
• Run the tool on machine other than that running the Application.
• Machine running the tool should have sufficient network bandwidth and resources(memory,CPU).
• Run the test for long duration to have minimum deviations.
• Ensure the application is stable and with no errors logged on log files by manually browsing the application.
• Incorporate the think time to emulate real life scenario.
• Keep Close watch on following (processor, memory,disk and network)

Don't

• Never run the test against servers which are not assigned to test, else you may be accused of DoS attack.

You can see more on performance testing on the blog http://prashantbansode.blogspot.in/

In the next article we will see how we can follow these guidelines and start on performance testing with JMETER!!

Basic Web performance Part 4

While previous articles we have loooked upon the website request response in more single user scenario. This may not be the case as most of company website / web product would be used by thousands/ millions of user. Some transaction might be used by few thousands users while some might be used by millions.It is advisable to properly test your website with more real life user distribution and this  cannot happen by manually and we need to automate the process.We need tools support and we have broadly categorize the tool into two classes
1. Open Source
2. Commercial
There might be more subtle difference before you choose a tool like protocol support, vusers support , learning curve  etc. Since our discussion is limited to web application we will focus on HTTP protocol here. The tools in open source category are OpenSTA, Jmeter while on another side commercial tools like LoadRunner , WebLoad, Rational tools. We choose Jmeter for our testingfor below reasons

1. Jmeter can be used for testing static and dynamic resource
2. Can support heavy load i.e. users
3. Great analysis for the performacne results/metrics
4. High extensible with support on javascript/groovy etc to enhance the script.
5. And Lastly No License Cost!!   

How to Install
Since it is open source you can do a quick googling , binging and get the executable download. More precisely you can go to
http://jmeter.apache.org/index.html and under download on left pane there is Download Releases latest is 2.9 version with prerequisites for java 6  . Under the binaries you can get the .zip or .tgz based on the operating system you are planning to install.For some reason you want to install older version you can go to Archives and download the version interested in.

Jmeter Launch
Once you have extracted the files , you will see bin,docs,extras,lib,printabledocs and few auxiliary files. You need to got to the bin folder and launch the jmeter.bat file this will launch the Jmeter and you will see something as below. The left pane on below screen contains the Elements of Jmeter and right pane is for configuration the settings for these elements.

We will talk more about the elements in jmeter in our next session and also touch base on some key terminologies in performance testing.

Basic Web Performance Part 3

In last articles we spoke about the measuring performance ; in this series we will continue our discussion and talk about measuring performance by analyzing the web logs . We will see how we can configure and capture the data in IIS web server logs . This raw data can be then analyzed with another free tool from microsoft called log parser. So lets get started.

Let me first show the steps to configure the logs. You need to go to your web server in inetmgr. In inetmgr go to website on left pane and select the same. Then go to Logging and click on the same . Below is pictorial representation of how to configure . Mostly we will select the following fields in logs
1. Time-Taken
2. bytes received
3. bytes send

Time taken is total time taken for request includes the time the request was queued , the execution time and rendering the response to client. The aspx request will include all these three component while the static component will only include time to client. The data transferred b/w client and web server can be calculated through bytes sent/received.

Once you have the raw data ; we will use the log parser  to analyze the data. The log parser is free utility from Microsoft and can be downloaded . You can run queries on the raw data through the log parser to get the status code , time taken etc. Here are few examples:

200 status Code
logparser -rtp:-1 "SELECT cs-uri-stem, cs-uri-query, date, sc-status, cs(Referer) INTO 200sReport.txt FROM ex0902*.log WHERE (sc-status >= 200 AND sc-status < 300) ORDER BY sc-status, date, cs-uri-stem, cs-uri-query"
400 status codes
logparser -rtp:-1 "SELECT cs-uri-stem, cs-uri-query, date, sc-status, cs(Referer) INTO 400sReport.txt FROM ex0811*.log WHERE (sc-status >= 400 AND sc-status < 500) ORDER BY sc-status, date, cs-uri-stem, cs-uri-query"
Bandwidth usage :Returns bytes (as well as converted to KB and MB) received and sent, per date, for a Web site.
logparser -rtp:-1 "SELECT date, SUM(cs-bytes) AS [Bytes received], DIV(SUM(cs-bytes), 1024) AS [KBytes received], DIV(DIV(SUM(cs-bytes), 1024), 1024) AS [MBytes received], SUM(sc-bytes) AS [Bytes sent], DIV(SUM(sc-bytes), 1024) AS [KBytes sent], DIV(DIV(SUM(sc-bytes), 1024), 1024) AS [MBytes sent], COUNT(*) AS Requests INTO Bandwidth.txt FROM ex0811*.log GROUP BY date ORDER BY date"
Bandwidth usage by request :Returns pages sorted by the total number of bytes transferred, as well as the total number of requests and average bytes.
logparser -i:iisw3c -rtp:-1 "SELECT DISTINCT TO_LOWERCASE(cs-uri-stem) AS [Url], COUNT(*) AS [Requests], AVG(sc-bytes) AS [AvgBytes], SUM(sc-bytes) AS [Bytes sent] INTO Bandwidth.txt FROM ex0909*.log GROUP BY [Url] HAVING [Requests] >= 20 ORDER BY [Bytes sent] DESC"

you can refer for more examples on http://logparserplus.com/Examples. You can output the IIS log file data into the csv and do more analysis.

In next series we will talk about the performance tools and dig more on open source tool JMETER and its capability.

Basic Web Performance Part 2

In last article we saw the importance of better performing Web site . So we need to make sure that our sites are performing better but before we work on improving the performance we need tool to measuring  the Web site performance. In this article and series of next articles we will talk about few tools which will help measure the performance . Here is list of tools we we look at.

1. Fiddler
2. Microsoft Network Analyzer
3. IIS Log files
4. 3rd Party Services

While we will have a look on top three we will not talk about the fourth one which is basically services that benchmark your web site against the different web sites. So lets start with Fiddler.
We touched upon some of core feature of Fiddler ; lets get started with practical. I will hit upon Microsoft.com and Fiddler will then capture and we will start analyze the data through various functionality provided by fiddler. Below is the screen shot of the request which gets generated upon hitting microsoft.com.

Timeline provides the graphical representation of the request response times .The data captured through the Fiddler can be saved for later reference. In image above the right panel shows the timeline , as you can see the aspx page got loaded in 2 seconds but the other  content on the site took 14+ seconds; which shows most of time is spend on downloading static resources.

There is another feature which is called Statistics which apart from other details lets us know the response bytes (by Content type) against the content which can determine the most consuming bandwidth data that can be looked upon for optimization.

 In above figure you can see the maximum bandwidth is used by the jpeg files and those are good sources of optimization.

Basics Web Performance -Part 1

Basics Web Performance

We need to know why do we care about the performance. While fast web sites makes customer happy there are other benefits of better performance , They  saves your money by

1. consuming less bandwidth
2. Consuming less servers

Better performing websites also help in generating more money ,

According to recent survey done on two web site Google and Amazon ; In amazon it was observed with every 100 ms increase in load time of Amazon.com the sales got decreased by 1% in another incident the home page of goggle maps when decreased from 100KB to 70-80KB traffic went up by 10% in first week and additional 25% in following three weeks.

Your web site performance also impact the ranking on Google. Now we know the importance of performance lets have a look at what makes web sites slow

The general assumption is the performance of website can be improved by tuning the code on server side.But with recent research it has been found that 10-20% of total response time is invested in processing the request  generating the HTML and getting it download. While rest of 80-90% time is invested on getting auxiliary files like image , javascripts, css etc. To demonstrate this we need to use the tool to see the conversation that happen b/w the browser and server. The conversation between the browser and server happen through HTTP protocol . The protocol stands for Hypertext Transfer Protocol ; it is text based protocol so we need some tool which can help profile http traces and one of the tool is Fiddler. This tool can watch the conversation that happen b/w browser and server

This tool is free and can be downloaded by doing small search on google ; The tools has various features

1. You can watch the web traffic
2. Shows complete request and response
3. Can save the session which can be used to compare the performance before and after
4. Transfer Timeline : graphical view of all the request made
5. Statistics is another feature in Fiddler.

We will talk about the fiddler and how we can see the response time on next post.....