On 08/05/2013 04:07 PM, David Kranz wrote:
On 08/05/2013 07:40 AM, Koderer, Marc wrote:
I see two use cases for stress tests:
- As a developer I want to find bugs that occur under load (like
raise conditions)
--> Leads to many small and concurrent api tests
- As OPS/QA I want to generate load that simulates real life load in a
production-like system
--> Leads to concurrent scenario test
IMO the most important use case for stress tests is the first. The idea
is to make something happen, like a race condition, that would only
happen rarely, and be much harder to debug, under real life load.
Simulating real life load is important for performance tuning and the
like but I think is a bit different. I don't see why the stress
framework should not be able to support concurrent scenario tests though.
hi David and thanks for contributing to this.
I agree on the idea that a stress test could address both the need of a
dev to stress a particular functionality as also the need of an op to
stress with concurrency a particular scenario, so I think this[1] is
welcomed and stress tests don't necessarily have to share a particular
structure.
At the same time, because of that some practical issues come into the
discussion. There is a submission[2] which basically is an attempt to
add some suspend/resume stop/start pause/unpause stress tests.
We either suggest to merge those into a single class and turn it into
some sort of stress scenario or keep them in different files but in that
case I wonder, how would that be different from just running the
existing api tests, for those same functionalities, concurrently via[1] ?
1. https://review.openstack.org/#/c/38980/
2. https://review.openstack.org/#/c/39752/
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: giulivo
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
