3 ms·

I'd do some more in depth checks. I find it very hard to believe you're cpu bound within NIO itself. I do around 1k req/s per cpu and never see load avg above

by axod 16y ago

I'd do some more in depth checks. I find it very hard to believe you're cpu bound within NIO itself. I do around 1k req/s per cpu and never see load avg above 0.5 >> "re-establish their connection back to the servers each time they receive a message or navigate to another page (or reload the page). This end up taking a big toll on the system. We're to some extent limited to how fast we can perform accept() on our sockets." I'd expect what you're seeing is the overhead of your system creating new objects initializing requests etc rather than anything low level. (Mibbit uses keep alive long polling XHR / websocket, using custom app server in Java +NIO)

cgbystrom 16y ago
It turns out that Java synchronizes on accept() capping the number of socket accepts that can made each second on a single port. But even if that would be solved or if you used something more low-level like, say nginx, you'd still be limited of how fast you can accept(). Try using ApacheBench and hit one server with keep-alive on and off respectively. Even nginx, which I would say is a performant web server, show quite some discrepancies between having to reconnect each time and having a permanent connection. I file this under the penalty of having to set up and tear down a socket each time. Something that only can be avoided by doing less reconnecting. I could of course be wrong but these are the findings from doing performance testing and discussing it on the Netty mailing list. But I'd gladly accept suggestions on how to improve this situation for our service.
- axod 16y ago
  I'd personally start by not using Netty if you have the time to start from scratch :/
  - cgbystrom 16y ago
    Netty is not the problem. Java NIO has that limitation. And performance isn't in any way bad, just that there's more to extract (I believe).
    - axod 16y ago
      > "Netty is not the problem. Java NIO has that limitation." As I say, I'd be interested in numbers to back that up. It's certainly not a limitation I've noticed.

by axod 16y ago

cgbystrom 16y ago

It turns out that Java synchronizes on accept() capping the number of socket accepts that can made each second on a single port. But even if that would be solved or if you used something more low-level like, say nginx, you'd still be limited of how fast you can accept(). Try using ApacheBench and hit one server with keep-alive on and off respectively. Even nginx, which I would say is a performant web server, show quite some discrepancies between having to reconnect each time and having a permanent connection. I file this under the penalty of having to set up and tear down a socket each time. Something that only can be avoided by doing less reconnecting. I could of course be wrong but these are the findings from doing performance testing and discussing it on the Netty mailing list. But I'd gladly accept suggestions on how to improve this situation for our service.

axod 16y ago
I'd personally start by not using Netty if you have the time to start from scratch :/
- cgbystrom 16y ago
  Netty is not the problem. Java NIO has that limitation. And performance isn't in any way bad, just that there's more to extract (I believe).
  - axod 16y ago
    > "Netty is not the problem. Java NIO has that limitation." As I say, I'd be interested in numbers to back that up. It's certainly not a limitation I've noticed.