10 ms·

Just because you don't need to process hundreds-of-thousands of messages per second doesn't mean that everybody is so fortunate.

• gridspy 16y ago
  Usually 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 ago
    There 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.