Tuesday, 10 September 2013

Evolving Customer Performance Requirement

Mostly the customer performance requirement are unambiguous and unrealistic. This is more clear from my recent experience with one of our customer. The key challenges are:-

1. performance requirement are very high level with accepted Metrics / workload not defined.
2. The tools and procedure for Performance evaluation is not defined.

Lets take each of this and see how we can involve customer in continuous engagement and avoid the last minute rush!

The requirement are defined with desired number of users and the acceptable response time. The initial gap we found around the distribution of users and the workload associated. Are these the realistic work load or are stressing the system in wrong way! Are we confirming to Customer needs which we cannot achieve! We initially told the customer all these issues and though we did not got complete details but we got two things the workload scenario and distribution. On seeing the scenario we immediately knew these are not realistic scenario and achieving the response time criteria with this scenario is not possible based on our experience but we went ahead so we could gather enough information on additional data like Hits/sec and Throughput and do compare against the market standard for similar tools.After multiple round of test we did various performance tuning but could not achieve the desire expectation. But we had enough data to show to customer that their needs are not realistic.

The was next challenge on the procedure involved for evaluating. The think times b/w transaction was 7-10 sec , user ramp up was not clear , peak load time not defined , content checks were done at each step , run time settings were completely default and all these were making the test failed at much lesser concurrency. After some discussion one of key difference was content checks and that was adding to the Load Runner response time as statement was executed for each vuser.

I suggest to add these learning to your case to better manage your customer requirement!

Wednesday, 28 August 2013

Evaluating Performacne the Customer Way!

We currently ran the performance testing for one of our prestigious customer.The tool we used for the test was load Runner . The test was supposed to be by two team one our team and another Customer team. We started the test on Customer database with 2500 CC and it got failed. The same test when run on our
internal Performance database and we have found that the test was scaling easily to 2500 CC and there comes out first learning

1. Evaluate the Volume of Database against when test is been done.
2. Evaluate the scenario against which UAT sign off is required.

Initial test runs failed and after multiple fixes we were able to successfully achieve 2500 CC. By the time we finished this test customer came up with his script and think time and we modified the script according to their think time and test again failed.Here comes my second learning

1. Never assume the think time even you are SME.
2. Hits/sec under certain concurrency is what Customer looks for.

Apart from the think time the customer did the URL mode scripting while we were doing the HTML based , currently we are running the test with context sensitive while out
Customer is running with Context Insensitive mode.

One can read moe about the Context Insensitive vs Context Sensitive on the blogs

Sunday, 30 June 2013

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!!