Kitura-NIO
Kitura-NIO copied to clipboard
Make the HTTPServer more configurable
Performance tests have shown that features that may be critical for certain workloads may prove to be an overhead for others. We need to make these features optional and provide a mechanism for users to opt in. Some of the configurable features:
- Idle socket detection and cleanup
- HTTP pipelining
- HTTP auto-error handling (e.g WebSocket upgrade workloads)
Secondly, performance tests have also shown that the optimum number of event loop threads at which the performance could peak is benchmark specific. This is because Kitura-NIO consciously choses to move the router handlers invocations to a Dispatch queue (and not on the event loop themselves). We then see two sets of tasks competing for CPU: one set are the event loops that accept incoming connections and deliver responses, the other set are the Dispatch threads that actually run the router handlers. Tests have proven that starving one set against the other slows down performance and it seems that, to maintain a balance, the number of event loop threads will have to be tuned experimentally by the user.
Of course, these allude to an API change.
cc @ianpartridge @djones6