Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Future: performance testing
Server side performance testing is painful,
ideally should be user need to define only what he wants to test (how to generate load).
Following parts needs to be implemented:
- JClouds - ssh to machine and run script
- binary distribution (no configuration)
- performance client (generating load)
- run as client
- generic API for collecting
- number of requests per time
- JConsole metrics (CPU usage, heap size, ...)
- generated bandwidth
- diagnostic tool
- how to detect that component performs bad?
- review tool
- how to plot graph?
- how to offer results for review?
- how to compare results with previous runs?
- continuous integration
- warm-up phase
Ideally, user needs to define only "what to test" - PerformanceClient. There should be pre-defined scenarios "how to test" - Controller.
Raw API: https://gist.github.com/1892743
- data from previous request's response as input of next request
- controllers written using eventing model similar to Arquillian SPI
- slow startup (gradual load increase)
Test suite (request URLs and parameters) needs to be defined first.
Selenium functional tests could be used as input generating performance suite descriptor.
In-container tests should be evolutionary:
- requests generated inside of container, hitting API methods
- measures components in separation - without influence of other layers (like view)