Our ActiveMQ brokers running on a single-core, 1gb, Digital Ocean node easily push 5k messages/s through ~200 queues and another several thousand/s through a couple hundred topics. They do reach a cliff edge though on single cores. Dual cores pretty much quadruples the throughput to the point where SSD latency is the problem.
Our Tomcat servers don't see 15k requests/s, but our load testing has shown a pair of them is good up to 3k/s (each) on dual-core 2gb servers with 512mb heaps. We really didn't push it much farther because that exceeds our needed capacity.
This is pretty boring technology. I'm fairly certain we could hit 15k req/s per node with plain Tomcat if we actually tried. I do think if you wanted to stretch past 15k req/s you probably do need more exotic programming models like Vert.X, but that does come at complexity.
I think the ultimate in throughput would be to have Tomcat listen on a unix domain socket (This is actually supported in Tomcat(https://github.com/apache/tomcat/commit/a616bf385a350175a33a...) and have TCP terminated with HaProxy (https://bz.apache.org/bugzilla/show_bug.cgi?id=57830). We set this up and it is _really really really_ fast, but we'd be on our own for support since nobody else is really doing it. Tomcat also has some strange behavior with the sock file, you kinda have to manage it on your own which is strange, but it could be done within the startup scripts.
Terminating the TCP with any kind of reverse-proxy and forwarding over a local TCP port to Tomcat would get you most of the benefit with very litte configuration and is a fairly standard setup.
It plays to the strengths of both becuase the reverse proxy handles long-lived but slow connections very well, and the Tomcat server gets to have fewer, but hotter threads.
That's actually our prod setup; we do that now and it's a pretty robust. As a bonus is gives you a nice "wiretap point" you can use tcpdump for debugging.
In our limited tests with HaProxy -unixDomainSocket-> Tomcat, we saw a significant increase in throughput and decrease in latency (when it worked). It got rid of our wiretap point though which is pretty handy, and we didn't _really_ need the performance increase. If I were to speculate, HaProxy is a rocket and beats even the mature codebase of Tomcat it seems when parsing http, and probably takes advantage of kernel features that haven't made its way into Tomcat yet. It wasn't prod-worthy stable, sometimes execution threads seemed to hang.
Multiple applications, not just a single on, powering call centers, not sexy SV stuff. Queues are used for two patterns: reliable data transport that we expect to be in near-realtime, and reliable event sourcing. The topics are mainly used non-reliable event signaling... for instance cache eviction (hey this row was updated, if you have it in your local cache, discard it or you'll get a conflict if you try to commit to the db). They also form the backbone for websocket broadcasting (sending messages to all of a users' app windows) Messages are all text/json or text/xml; I'd say 512b-8kb with an average around 1k. Data transmission messages are on the large end of that; signalling messages are on the small side of that.
Interesting application, thanks for the background it helps put your original comment in a bit more perspective. As for it not being 'sexy SV stuff' -> most important automation projects aren't and they tend to be far more interesting than the stuff that is supposedly sexy. I've helped build a system that routes a sizeable fraction of all container and bulk freight around the world and when looked at from the outside it is probably pretty boring but the guts of it were fascinating. Not to mention mission critical to a degree that very few other things (healthcare, avionics) are. Telco has a ton of interesting challenges like that.
Our Tomcat servers don't see 15k requests/s, but our load testing has shown a pair of them is good up to 3k/s (each) on dual-core 2gb servers with 512mb heaps. We really didn't push it much farther because that exceeds our needed capacity.
This is pretty boring technology. I'm fairly certain we could hit 15k req/s per node with plain Tomcat if we actually tried. I do think if you wanted to stretch past 15k req/s you probably do need more exotic programming models like Vert.X, but that does come at complexity.
I think the ultimate in throughput would be to have Tomcat listen on a unix domain socket (This is actually supported in Tomcat(https://github.com/apache/tomcat/commit/a616bf385a350175a33a...) and have TCP terminated with HaProxy (https://bz.apache.org/bugzilla/show_bug.cgi?id=57830). We set this up and it is _really really really_ fast, but we'd be on our own for support since nobody else is really doing it. Tomcat also has some strange behavior with the sock file, you kinda have to manage it on your own which is strange, but it could be done within the startup scripts.