Q.1 I know that when we are talking about synchronous HTTP, for each request a Thread may be spawn and get blocked, so when number of simultaneous connections increase, we will encounter massive thread overhead.
Asynchronous mode will tolerate some overhead polling responses for something desired, but number of Threads drastically decrease.
I also know that Asynchronous HTTP will let us take actions even when response delivered is not the complete response (only a part of response is received) which is appropriate for real-time actions.
But what are other benefits of Async HTTP?
Q.2 I have a server which has only and only one client, but that client will send thousands of requests per second. I use blocking IO (Synchronous HTTP) with lightweight Threads (Quasar). Should I switch to Async? What is the benefit of doing that for me?
EDIT. More clarifications. I have an HTTP server with 3-4 thousand requests from the same client per second, and I have only one client. I solved the problem of thread overhead by using lightweight threads in conjunction with synchronous HTTP (say blocking IO) instead of using Async HTTP.
Now I don't know if removing thread overhead was all the job I had to do, or will I face some other problems later because of not using Async API? (And this is maybe because I don't know full benefits of Async API which means Q.1)
Regards
-
1Welcome to Programmers.SE! You might want to check out: What topics can I ask about here?– Adam ZuckermanJun 7, 2016 at 15:37
-
My question is about programming concepts. I see no violations.– Alireza MohamadiJun 7, 2016 at 15:38
-
3You are asking for a list of opinions or options in both questions. That is off topic.– Adam ZuckermanJun 7, 2016 at 15:40
-
1It is not opinion based. It is question dude. I'm not asking about opinions.– Alireza MohamadiJun 7, 2016 at 15:41
-
1I don't think "list of opinions" is the best way to describe what's wrong with this question; for me it's just completely unclear what sort of help you're looking for, as you appear to have already answered half of your question, and you haven't told us anything about your project so how could we possibly know if non-blocking I/O is appropriate?– IxrecJun 7, 2016 at 20:34
|
Show 3 more comments
1 Answer
The benefit of asynchronicity in any context is that the user does not have to wait for the method call to complete. This has benefits most specifically in UI's, where not blocking on a method call results in the UI appearing to be more responsive to the user.
The answer to "should I switch to async?" is "will it improve the responsiveness of the application?" Only you can decide that, based on your observations of your specific application's behavior. In general, you would only use async (if at all) for methods that take a long time to complete, for some arbitrary definition of "long."
answered Jun 7, 2016 at 15:43
-
3This seems very limited to just the GUI context. In a webserver case, I'd say the main benefit is that it preventing request threads from being "useless" while they wait for blocking IO calls. I think it's a scalability issue as much as it is a responsiveness issue.– saraJun 8, 2016 at 6:26
-
@kai: Yep, that's the whole point: keep the process as busy as possible to avoid context switch as much as possible. Jun 8, 2016 at 6:31
-
in asynchronous mode most of the time events are pushed into a queue. because of this you can prioritise, split, filtering, doubling up according to your need.... which in turn makes you app smarter, and faster. Nov 2, 2016 at 14:34