1

This topic was on my mind for a long time.

Let's assume we have a typical web server, one in Node.js and the other in Java(or any other language with threads).

Why would node perform better (handle more IO/network based requests per second) than a java server just because it uses async/await? Isn't it just a syntatic sugar that utilizes the same threads java/c#/c++ use behind the scenes?

Two Horses
  • 1,401
  • 3
  • 14
  • 35
  • I recommend reading this: https://subscription.packtpub.com/book/web_development/9781783287314/1/ch01lvl1sec09/the-reactor-pattern – eol Aug 16 '20 at 11:42
  • "Why would node perform better than a java server" - I guess it would not. Did you ran a benchmark? And it is possible to write asynchronous java server, without async/await, but which runs parallel. – Alexei Kaigorodov Aug 16 '20 at 14:43

3 Answers3

4

There is no reason to expect Node to be faster than a server written in Java. Why do you think it might be?

It seems the other answers here (so far) are explaining the benefits of asynchronous programming in JS compared to single-threaded synchronous operations -- that's obvious, but not the question.

The key point everyone agrees on is that certain operations are inherently slow (e.g.: waiting for network requests, waiting for disk/database access), and it's efficient to let the CPU do something else while such operations are in flight. Using several threads in your application is one well-established way to do that; but of course that's only possible in languages that give you threads. Many traditional server implementations (in Java, C, C++, ...) use one thread per request (or, equivalently, a thread pool to distribute incoming requests over). These threads can block waiting for, say, the database -- that's okay, the operating system will put the waiting thread to sleep and let the CPU work on another thread (handling another request) in the meantime. The end result is fairly similar to what you get with Node.

JavaScript, of course, doesn't make threads available to the programmer. But instead, it has this concept of scheduling requests with the JavaScript engine and providing a callback to be invoked upon completion of the request. That's how the overall system behaves similarly to a traditional threaded programming language: user code can say "do this stuff, then schedule a database access, and when the result is available, continue with this [callback] code here", and while waiting for the database request, the CPU gets to execute some other code. What you want to avoid is the CPU sitting around idly waiting while there is other work waiting for the CPU to have time for it, and both approaches (Java threads and JavaScript callbacks) accomplish that.

Finally, async/await (just like Promises) are indeed just syntactic sugar that make it easier to write callback-based code. Code using async/await isn't any faster than old-style code using callbacks directly, just prettier and less error-prone. It also isn't any faster than a (well-written) Java-based server.

Node.js is popular because it's convenient to use the same language for the client and server parts of an app. From a performance point of view, it's not better than traditional alternatives, it's just also not worse (or at least not much; in practice how efficiently you design your app matters more than whether you implement it in Java or JavaScript). Don't fall for the hype :-)

jmrk
  • 34,271
  • 7
  • 59
  • 74
  • 1
    "*using async/await isn't any faster than old-style code using callbacks*" - that's not what https://v8.dev/blog/fast-async is trying to tell us :-) But yes, neither is *inherently* faster than the other. – Bergi Dec 08 '20 at 12:15
0

Asynchrony(asyn/await) is essential for activities that are potentially blocking, such as when your application accesses the web. Access to a web resource sometimes is slow or delayed. If such an activity is blocked within a synchronous process, the entire application must wait.

In an asynchronous process (thread), the application can continue with other work that doesn't depend on the web resource until the potentially blocking task finishes.

https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/hh191443(v=vs.110)?redirectedfrom=MSDN#threads Though you should understand the differences between threads and async/await programming.

harshadkapei
  • 13
  • 5
  • I read the link you sent and I understand that async/await won't create a background thread, but how so? If you make a DB request, you have to have a background thread that listens to the response, no? Then what is the benefit of async/wait over threads? (besides the cleaner syntax) – Two Horses Aug 16 '20 at 10:32
  • A thread can do many more useful things. Await is specifically designed to deal with something taking time, most typically an I/O request. Which traditionally was done with a callback when the I/O request was complete. Writing code that relies on these callbacks is quite difficult, await greatly simplifies it. – harshadkapei Aug 16 '20 at 12:12
0

In regards to Asynchronous programming, Usability is the key. For instance, one request can be split up into smaller tasks i.e. fetching into internal results, reading, writing, establishing connections etc... thus, half the time gets wasted waiting on dependent tasks. Asynchronous models use this time to handle other incoming requests keeping a callback function, registering in a queue saving the state and becomes available for another request. Thus, they can handle more requests.

Understand more on handling requests: https://www.youtube.com/watch?v=cCOL7MC4Pl0

Adrian Mole
  • 49,934
  • 160
  • 51
  • 83
Deepika Sharma
  • 1
  • 1