1

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

  • 1
    Welcome to Programmers.SE! You might want to check out: What topics can I ask about here? – Adam Zuckerman Jun 7 '16 at 15:37
  • My question is about programming concepts. I see no violations. – Alireza Mohamadi Jun 7 '16 at 15:38
  • 3
    You are asking for a list of opinions or options in both questions. That is off topic. – Adam Zuckerman Jun 7 '16 at 15:40
  • 1
    It is not opinion based. It is question dude. I'm not asking about opinions. – Alireza Mohamadi Jun 7 '16 at 15:41
  • 1
    I 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? – Ixrec Jun 7 '16 at 20:34
5

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."

  • 2
    This 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. – sara Jun 8 '16 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. – slebetman Jun 8 '16 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. – Junchen Liu Nov 2 '16 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.