3 ms·
Article is better than expected. Because it looks like the application itself isn't doing much at all (receive message over socket, touch some memory) you're pr
by gizmo 16y ago
Article is better than expected. Because it looks like the application itself isn't doing much at all (receive message over socket, touch some memory) you're probably better off with a simple thread pool and some lock free data structures if you're really going for raw performance. On the other hand, it does serve as another data point that a Java solution can be fast enough.
Anyway, I think that thinking in terms of "message throughput" is really harmful. The author starts with a throughput of 120.000 messages per second and ends up with 800.000 messages per second which gives the advertised 6 times speedup. But essentially at 120.000 messages per second you have a "process overhead" of a mere 0.008 milliseconds. That's 8 microseconds. Microsecond!
I'll just repeat that. Overhead of 0.008 milliseconds per message in the SLOW case. So if you want to write the message to file, or do any kind of hash table lookup or want to do any kind of back end processing, whether you have 0.008 milliseconds or 0.002 milliseconds overhead per message is not going to be that big of a deal.
- alextingle 16y agoJust because you don't need to process hundreds-of-thousands of messages per second doesn't mean that everybody is so fortunate.
- gridspy 16y agoUsually the 'real work' required to process the message would drown this overhead in the noise. The moment the message requires you to establish an outgoing connection, open a file, hit the database or something similar it is going to completely blow this throughput. Also, it seems that the overhead here is poor use of shared memory or threading semantics, something we cannot debug without the source (and the required time)
- viraptor 16y ago> it seems that the overhead here is poor use of shared memory or threading semantics Worth noting on the graphs - even though CPUs aren't maxed out, they add up to (roughly) just above 100%. That just shouts "lock contention / thread switching".
- alextingle 16y agoThere are plenty of 'real' workloads that don't involve opening a file, hitting a database or establishing an outgoing connection. Even a relatively simple task like serving up a web-app uses caching heavily to avoid being bogged down by the grinding slowness of disk access. If he's aiming for performance, then the message processing overhead could be very significant, and is worth optimising.
- Legion 16y ago>> Article is better than expected. That's because usually people use click-whoring titles to try and get you to add a page hit to a crappy blog post. This guy used a click-whoring title to serve you up a totally awesome article.