Breakpad/Design/Loadtesting: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
The main reason why we use log replay is that it's a better way to imitate actual load than AB (AB tests the cache and is only one page). | The main reason why we use log replay is that it's a better way to imitate actual load than AB (AB tests the cache and is only one page). | ||
Set up [https://bugzilla.mozilla.org/show_bug.cgi?id=383744 bug 383744] to track progress. | |||
==General Approach== | |||
Since we don't fully know what our required req/s capabilities are with what concurrency, here are some of the preliminary things we should find with our first run: | |||
* where the current bottleneck is | |||
* how we can improve it | |||
* where other weak points in performance are | |||
We should be able to use [http://docs.python.org/lib/module-profile.html python profiling] to profile all three pieces. It should help us find problem areas. | |||
==Stuff We Need to Start Testing== | |||
* Need collector logs and example post data to send to collector. | |||
* Need reporter logs to replay. | |||
==Collector== | ==Collector== | ||
==Processor== | ==Processor== | ||
The processor will be the tricky part, but it's more scalable than the other pieces since we control the rate. | The processor will be the tricky part, but it's more scalable than the other pieces since we control the rate. It would be useful to build in some rate or time tracking pieces to the processor so we understand how fast it can process reports. | ||
==Reporter== | ==Reporter== | ||
Latest revision as of 17:46, 8 June 2007
Load Testing Plan
Below is a list of items we plan on doing for load testing. In general, the best way we've had to test load has been to:
- Get an estimate of our concurrent load
- Get log samples
- Use oremj's log replay script to replay logs and check results
The main reason why we use log replay is that it's a better way to imitate actual load than AB (AB tests the cache and is only one page).
Set up bug 383744 to track progress.
General Approach
Since we don't fully know what our required req/s capabilities are with what concurrency, here are some of the preliminary things we should find with our first run:
- where the current bottleneck is
- how we can improve it
- where other weak points in performance are
We should be able to use python profiling to profile all three pieces. It should help us find problem areas.
Stuff We Need to Start Testing
- Need collector logs and example post data to send to collector.
- Need reporter logs to replay.
Collector
Processor
The processor will be the tricky part, but it's more scalable than the other pieces since we control the rate. It would be useful to build in some rate or time tracking pieces to the processor so we understand how fast it can process reports.