This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
The receive timeout setting for a poller may also be important. For example, if you have a long receive timeout, the threads will be in a timed-wait state and able to respond immediately. On the contrary, with a short timeout and longer interval, the messages may sit in the channel longer. Of course, this is more about "responsiveness" than "throughput" per se, but when you are dealing with a lot of messages, they are of course related.
We are running JMeter which is configured to start 1000 threads(users) and get an update of sorts.
Below is our starting point configuration. We have a huge server and plenty of memory. When pushing the channel up to 20 we see no improvement in response/thru-put. I suspect we are doing something wrong.
I don't see how reusing the same executor for different endpoints would make a great difference with using a dedicated pool for consumption. If it does I feel we should repair that in the framework. I think it is overly complicated if you have to manage multiple threadpools in most scenarios.
Could you comment on that (and create an issue if it doesn't work well)?
Obviously if it works for you it would be moronic for me to say that it's wrong. I would like it to work without the three thread pools. You should be able to get the same performance with a single thread pool imho. Since you have clearly given this a great deal of attention I'd like to see if perhaps Spring Integration is wrong. Did you reproduce your performance results in a standalone app we can test with?