-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server HttpConnectionHandler optimization (remove flatmap) #164
Milestone
Comments
NiteshKant
pushed a commit
to NiteshKant/RxNetty
that referenced
this issue
Jul 2, 2014
Removed the use of flatMap() with a custom operator.
NiteshKant
pushed a commit
to NiteshKant/RxNetty
that referenced
this issue
Jul 3, 2014
Removed the use of flatMap() with a custom operator. Use Subscriber instead of Observer
NiteshKant
pushed a commit
to NiteshKant/RxNetty
that referenced
this issue
Jul 3, 2014
ReactiveX#164: Removed flatMap() usage in HttpConnectionHandler in favor of a custom operator. ReactiveX#166: Defined a facility to also specify the acceptor event loop. RxNetty defaults to an acceptor event loop with 1 thread. Also, the number of worker threads == number of available processors. ReactiveX#167: Not sending Connection: keep-alive for HTTP 1.1. protocol
Merged
NiteshKant
added a commit
that referenced
this issue
Jul 3, 2014
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Based on our benchmarking the use of
Observable.flatMap()
insideHttpConnectionHandler
here incurs an unnecessary overhead.The below flamegraph shows the overhead:
In this particular instance,
flatMap()
does not seem to be useful, it can easily be replaced by a custom operator which connects theconnection.getInput()
's onComplete() and onError() to the subscriber ofHttpConnectionHandler.handle()
The result ofRequestHandler.handle()
does not impact the subscriber ofHttpConnectionHandler.handle()
The text was updated successfully, but these errors were encountered: