[Java] stress testing tool

[thomers1]

i'd like to stress test our setup, and i thought i use the java client API for that.

do you have any recommendations for a test framework? i looked into grinder, but i'm not too sure about python.

thx
thomers

[ThomasLund]

There are lots of options - depending on what you need and your $

You can use jUnit testcases running inside e.g. continuous integration platforms like Atlassian Bamboo (payware) or CruiseControl

Might be overkill if you dont want generally to do testdriven development.

You can also use JMeter together with JUnit cases - this might be more feasable solution for load and stress tests. Can collect data and make nice graphs for you.

By the end of the day it might be just a simple to code up your own threaded launcher that wraps (again) JUnits.

And once you got the JUnits, then why not do test driven development anyways?

And lastly - take a look at PureLoad: http://www.minq.se/products/pureload/

Payware, but (somewhat defacto standard)

[Lapo]

I think grinder is for http only? We used it as one of the tools for testing the BlueBox. Not bad but performance is not very high, probably due to the python overhead.

Building a basic tool that simulates many connections and sends/receives messages isn't particularly complex, the difficult part is making it interact correctly with your application as a real user/player would do.

A possible high-level solution is to use our API for Actionscript 3.0 or Java. We've recently done a few tests using an Actionscript3 stress client and we were able to run around 4-500 concurrent clients in a single Flash Player instance, we didn't expect that much!
By using multiple Flash Player instances and multiple client machines you can easily simulate thousands of concurrent clients.

All you need to do is create a client that logs in, joins the right room (maybe with the help of the server side), and starts acting as if it was playing.
Once you have this test class, you can build a "Test Manager" class that manages the generation of hundreds of these clients.

Finally we suggest multiple strategies for testing an application: automated tests can be used to hammer spefic areas of the application that could be potentially problematic (i.e. database access, other server-side heavy jobs) and also a live public-beta for testing overall stability and efficiency of the service.
This allows to receive a lot of feedback from real users which in turn helps discovering other problems that usually slip to the developer's eyes

[thomers1]

All you need to do is create a client that logs in, joins the right room (maybe with the help of the server side), and starts acting as if it was playing.

yes, i'm just thinking about a good way to implement that asynchronous behaviour of sending a command to the server, and then waiting for a response, before issuing the next command.

something like a queue with command-objects, one is taken and sent to the server, and waits until another thread is reading the response and deciding if the last command was successful or not... triggering the next command (or resending the last one) via the other thread.

makes sense?

[Lapo]

Sure, that can be a good approach