How do you load/stress test Spring Integration?

[teisemann]

Hi all

simple question - want to generate some load test scenarios by publishing lots of event/messages to different channels.

Wondering if someone has already done this and has some test scaffolding to help

was thinking of use DDsteps or similar for data driven testing. But need to have a nice multithreaded message generator - maybe Grinder or something.

If there is anything like this used in testing the Spring Integration project itself, I'd love to learn about it.

any response is appreciated

thanks

[iwein]

We haven't got that inside the framework. My expectation is that it is very much dependent on the implementation you're doing what the results may be. Of course you might trigger some concurrency or performance problems that you can feed back into the framework.

To generate messages concurrently you could just implement a message source and attach a poller to it that uses a thread-pool-task-executor. On the other hand using an external tool will minimize the chances of confusing the performance of the system with the performance of the test harnass.

Be sure to feed back your results, it will be very interesting to see if how SI measures up. Thanks!

[dudleygb]

you could modify some of the sample apps main methods and just spawn a couple of those?

[iwein]

you could modify some of the sample apps main methods and just spawn a couple of those?

Actually you can do better than that. The CafeDemo sample drops messages in a queue in a loop. There is no delay in the handoff (as long as the queue has capacity). If you give the orders channel a queue with high capacity and loop a little longer you can clearly see the system takes a long time to process after the messages have been dropped in the queue.

If you then add a

	<poller default="true" task-executor="pool">
		<interval-trigger interval="10" />
	</poller>
	<thread-pool-task-executor id="pool" max-size="50" />

to the cafeDemo.xml (and remove the poller children from the endpoints) you can see the multiple threads working for you. The hard part is to analyze the system obviously.

The main thing I'd have against using the CafeDemo sample is that it has a Thread.sleep(..) to simulate IO. This isn't the same thing of course, so you should for example pull something from the network or disk instead.