fixd icon indicating copy to clipboard operation
fixd copied to clipboard

Improve performance in relation to asynchronous requests

Open lantunes opened this issue 10 years ago • 2 comments

Currently, an asynchronous request results in a thread-per-request. Replace this approach with another that uses a single additional thread, a Selector, and NIO. The SocketChannel is accessible through the Request.

lantunes avatar Jun 15 '14 12:06 lantunes

Perhaps the user should be given the option of using either the thread-per-asynchronous-request model, or the NIO-based model. Perhaps there may be scenarios where the thread-based model results in better performance?

lantunes avatar Jun 15 '14 14:06 lantunes

The current broadcast-subscribe process with Simple can be improved. Instead of starting a new thread for each subscriber, and having that subscriber thread block on a queue of broadcasts, we can have a single broadcaster thread that starts at startup. Subscribers, with a reference to the Response, register with the broadcaster. This way, the Container can simply create a subscriber and give it to the broadcaster and return immediately.

The same cannot be done for after() and every(). Perhaps these can be improved with an NIO loop that stores the current time (see SelectionKey.attach()) and checks if the required amount of time has elapsed?

lantunes avatar Jun 20 '14 09:06 lantunes