General: Planning for Load Testing - Soliciting Requirements
1 Comments Published by Hs on Saturday, July 21, 2007 at 12:53 AM.
Prior to this stage, I always give a “sales talk” of what we do for a living and also to get them excited (if they are not). Gathering and soliciting accurate requirements will save you lots of unnecessary work.
Be sure to get hold of the requirements to monitor such as acceptable Transaction Response Time or server utilization. Clients need to be clear of what they want before you can proceed to achieve (unless is you who proposes the benchmark). For example, if CIO wants the response time for a search to be fewer 10 seconds will be a good metric to achieve. This is also the exit criteria as per se for the load test project.
They may also like to know the utilization of the servers under load and not really concerned with the response time. Usually, these are applications that are already problematic and it’s what they are hiring you to dig the cause of the bottleneck.
Always get an overview of the architecture which includes all components that inhabitant it. You can leave out the number of switches or routers if they do not provide much usage except routing and separating networks. It is important to get information like number of servers and what is housed in it, load balancers, firewall and databases. This will aid you in discussion and knowing what machines to be monitored.
Assist the clients in understanding which business process may raise performance issues or they see it’s criticality in the business competitive edge. With this, it can translate into the scripts that will be used in the load test.
Related Topics
General: Planning for Load Testing
General - Content Page
Be sure to get hold of the requirements to monitor such as acceptable Transaction Response Time or server utilization. Clients need to be clear of what they want before you can proceed to achieve (unless is you who proposes the benchmark). For example, if CIO wants the response time for a search to be fewer 10 seconds will be a good metric to achieve. This is also the exit criteria as per se for the load test project.
They may also like to know the utilization of the servers under load and not really concerned with the response time. Usually, these are applications that are already problematic and it’s what they are hiring you to dig the cause of the bottleneck.
Always get an overview of the architecture which includes all components that inhabitant it. You can leave out the number of switches or routers if they do not provide much usage except routing and separating networks. It is important to get information like number of servers and what is housed in it, load balancers, firewall and databases. This will aid you in discussion and knowing what machines to be monitored.
Assist the clients in understanding which business process may raise performance issues or they see it’s criticality in the business competitive edge. With this, it can translate into the scripts that will be used in the load test.
Related Topics
General: Planning for Load Testing
General - Content Page
Labels: Load Testing, Performance Testing, Planning
Bookmark this article now!
One major problem typically occurs while planning for load testing. The technical team is called upon to translate business requirements (numbers of users, types of services, customer care volumes, etc...) into downstream transaction rates. The translation is often flawed and the results is a lack of consensus among teams, misunderstanding of SLA requirements and at worst an under or over investment that either costs the company too much or causes a service impacting event. We have found that the most critical aspect of requirements gathering when preparing for load testing is in mapping the market demand loads to the downstream process transactions. This eliminates the confusion across departments and ensures that the planned tests use highly probable loads rather than a plug number such as 2x or 5x some transaction rate in which confidence is not high. The impact is worse when multiple coincident loads need to be tested. Defining highly probable coincident loads is critical to ensure the tests capture the right scenarios.