Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
1–10 of 59 posts
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#2Line for line Go will be faster it is compiled.
It is the only thing that matters line for line.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#3The ease of use chart is a joke:
Java: Requires callbacks
nodejs: Requires Callbacks
Java has pretty much whatever you want. Akka, futures/promises, etc.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#4Line for line Go will be faster it is compiled. It is the only thing that matters line for line.
No, it's not the only thing that matters. Java's compiled too and was included here, but Go still beat it out.
It's likely that C or Rust or C++ would be much faster than Java or Go since they have large runtime overheads; it turns out having a runtime and how heavy it is matter too, not just if it's compiled.
There are also cases where non-compiled languages can beat out compiled ones. For example, lua with LuaJIT is incredibly fast, and beats out compiled languages with heavy runtimes (like java/C#) in quite a few microbenchmarks.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#5The example of async I/O in Node.js is with a filesystem operation.
How does that work? AFAIK Linux, unlike windows, doesn't have a proper async API for filesystem I/O.
POSIX AIO is implemented using threads in libc and Linux AIO (io_submit, etc) only works with O_DIRECT (no kernel caching) and there are other issues depending on underlying filesystem driver.
Is there any solution?
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#6The example of async I/O in Node.js is with a filesystem operation. How does that work? AFAIK Linux, unlike windows, doesn't have a proper async API for filesystem I/O. POSIX AIO is implemented using threads in libc and Linux AIO (io_submit, etc) only works with O_DIRECT (no kernel caching) and there are other issues depending on underlying filesystem driver. Is there any solution?
Yes a user space thread pool which is what node.js does on top of libuv.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#7The example of async I/O in Node.js is with a filesystem operation. How does that work? AFAIK Linux, unlike windows, doesn't have a proper async API for filesystem I/O. POSIX AIO is implemented using threads in libc and Linux AIO (io_submit, etc) only works with O_DIRECT (no kernel caching) and there are other issues depending on underlying filesystem driver. Is there any solution?
https://nikhilm.github.io/uvbook/filesystem.html
> The libuv filesystem operations are different from socket operations. Socket operations use the non-blocking operations provided by the operating system. Filesystem operations use blocking functions internally, but invoke these functions in a thread pool and notify watchers registered with the event loop when application interaction is required.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#8I was reading the article until a giant fullscreen ad popped up and I had to close the tab. Sorry, no thanks.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#9The article talks about IO, but then benchmarks sha256. The node program doesn't work well because he's synchronously doing this:
for (var i = 0; i Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#10I'm curious, which Java servers are creating a new Thread per request?
Tomcat uses acceptors threads and a request executor pool. And, if available on your platform (which it probably is), it defaults to using non-blocking IO instead of polling.
EDIT: It looks like he does acknowledge the executor threads are pooled. His main criticism is that "too many blocked threads are bad for a scheduler". But if Tomcat is using the NIO connector this doesn't apply, because your executor threads won't block on IO. And typically the pool size is limited to something manageable by a modern CPU (200 or so)