微軟有出一本書叫
Improving .NET Application Performance and Scalability
這本書是在描述微軟如何做Performance engineering. 其中有一章節是在描述如何做performance testing. 我節錄了一小段讓大家聞香一下. 有興趣的人可至微軟網站download這本書. 不過有一千多頁, 要花不少時間才能看完.
Step 1: Identify key scenarios
(1) Scenarios are anticipated user paths that generally incorporate multiple application activities
(2) Scenarios are those for which
- Have specific performance goals
- Have a significant performance impact (common executed or resource intensive)
(3) Example
- Log on to the application
- Browse a product catalog
- Search for a specific product
- Add items to the shopping cart
- Validate credit card details and place an order
Step 2: Identify Workload
(1) Identity the performance characteristics or workload associated with each of the defined scenarios
(2) For each scenarios you must identify the following:
- Number of users:
* the total number of concurrent and simultaneous users who access the application in a given time frame
- Rate of requests
* The requests received from the concurrent load of users per unit time
- Pattern of requests
* A given load of concurrent users may be performing different tasks using the application
* Pattern of requests identify the average load of users, and rate of requests for a given functionality of an application
Step 3: Identify Metrics
(1) Identify the metrics that you need to measure when you run your tests
(2) As you progress through multiple iterations of the tests, you can add metrics based upon your analysis of previous test cycles
(3) You can monitor metrics under the following categories
- Network-specific metrics (routers, switches, and gateways…)
- System-related metrics(CPU, memory, disk I/O,network I/O…)
- Platform-specific metrics (.NET common language runtime, ASP .NET –related metrics)
- Application-specific metrics : use custom performance counter inserted in your application code to monitor AP health and identify performance issues
- Service level metrics: measure overall AP throughput and latency, or they might be tied to specific business scenarios
(4) After identifying metrics, you should determine a baseline for them under normal load conditions
Step 4: Create Test Cases
(1) Document your various test cases for the workload patterns identified in step 2
(2) Example : simple e-commerce AP
- Number of user : 500 simultaneous users
- Test duration : 2 hours
- Think time : Random think time between 1 and 10 SECs after each operation
- Workload
- Expected Result
* Throughput: 100 requests per second (ASP.NET – Request/sec performance counter)
* Requests Executing: 45 request executing (ASP.NET – Requests Executing performance counter)
* Avg. Response time: 25 second response time (TTLB on 100 megabits per second [Mbps] LAN)
* Resource utilization thresholds
Processor - Processor Time : 75 percent
Memory – Available M Bytes : 25 percent of total physical RAM
Step 5: Simulate Load
(1) Use tools to run the identified scenarios and to simulate load
(2) To generate the test data, continue to increase load incrementally for multiple test iterations until you cross the threshold limits set for your application
(3) If you continue to increase load during the testing process, you are likely to ultimately cause your application to fail.
Step 6: Analyze the results
(1) Analyze the captured data and compare the results against the metric’s accepted level.
(2) You can identify bottlenecks in the application by analyzing the metric data
- You need to investigate the cause, fix or tune your application, and then run the tests again.
- Based upon your test analysis, you may need to create and run special tests that are very focused
Reference
Improving .NET Application Performance and Scalability, Microsoft Press
Chapter 16 Testing .NET application performance