I visited the post fully expecting the author would benchmark the latest PHP 7.2. To my surprise, he wasn't even benchmarking 7.0, but the old 5.6. I can't take this test seriously.
Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
11–20 of 59 posts
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#12The 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.
I'm not familiar with libuv but is there a dedicated "watcher" thread in a thread pool that the kernel wakes up when when the disk driver has completed that I/O that it was sleeping on? If so is there a dedicated "watcher" thread for each non-blocking I/O request handled by libuv?
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#13I visited the post fully expecting the author would benchmark the latest PHP 7.2. To my surprise, he wasn't even benchmarking 7.0, but the old 5.6. I can't take this test seriously.
Agreed.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#14The 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 He should be using crypto and the async versions. This benchmark actually is just measuring the speed of your sha256 implementation, which I would guess is equal on all 4 platforms if you actually do them correctly.
Where did you even find the source code?
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#15I'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…
Yeah that perplexed me as well. There's no reason you can't get a modern Java app server to do async io coupled with thread pools and achieve performance close to Go. Maybe Go's coroutines vs Java native threads may give Go a little advantage but it shouldn't be a great difference for sanely designed applications.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#16I visited the post fully expecting the author would benchmark the latest PHP 7.2. To my surprise, he wasn't even benchmarking 7.0, but the old 5.6. I can't take this test seriously.
Same applies to his Java related choices.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#17So he acknowledges that has not benchmarked the best options for Java and then selects Go as a winner, what a joke.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#18I'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…
Yeah that perplexed me as well. There's no reason you can't get a modern Java app server to do async io coupled with thread pools and achieve performance close to Go. Maybe Go's coroutines vs Java native threads may give Go a little advantage but it shouldn't be a great difference for sanely designed applications.
Netty would be one possible option, but he selectively left out everything that could jeopardize Go's victory.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#19I was reading the article until a giant fullscreen ad popped up and I had to close the tab. Sorry, no thanks.
Same happened to me. And there was no way to close it. I did a hard refresh and it loaded again without the popup - I'm guessing it's on a time delay? Either way, super annoying.
Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go
#20The 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 He should be using crypto and the async versions. This benchmark actually is just measuring the speed of your sha256 implementation, which I would guess is equal on all 4 platforms if you actually do them correctly.
Where did you even find the source code?