Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

toptal.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#51

Post by bogomipz »

dullgiulio wrote: post #47
bogomipz wrote: post #12

Earlier quoted context omitted.

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?

There is no watcher: threads get parked by the kernel as "not runnable" while they perform the I/O operation. When the operation is finished, then they become runnable again so the kernel scheduler runs them--that is, it runs the code that comes after the I/O operation. This code (from libuv) notifies the requester that the operation is complete.

Thanks. So is the libuv package implemented as two distinct components then consisting of:

1) The main event loop thread.

2) a thread pool of "workers" which make the actual I/O request and sleep while waiting for the I/O. Then when a "worker" thread is set to runnable again by the kernel(because it's I/O request has been completed)notifies the main event loop thread via a signal?

Is that correct?

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#52

Post by justboxing »

glitcher wrote: post #21

Pet peeve: tech articles/blogs which do not prominently display when the article was written. This is the single most important fact I search for before reading time sensitive tech info. I can't tell when this was written, am I missing something?

Yeah, super annoying. They likely have some content marketing campaign that shares old posts at various intervals.

Looks like it was published 6 months ago - 'Thu, 11 May 2017 09:14:20 -0400' to be precise.

Source: The /rss feed for the blog, which shows the following for this post.

    
      Server-side I/O Performance: Node vs. PHP vs. Java vs. Go
      Understanding the Input/Output (I/O) model of your application can mean the difference between an application that deals with the load it is subjected to, and one that crumples in the face of real-world uses cases. Perhaps while your application is small and does not serve high loads, it may matter far less. But as your application’s traffic load increases, working with the wrong I/O model can get you into a world of hurt.
      Thu, 11 May 2017 09:14:20 -0400
      https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go
      server-side-io-performance-node-php-java-go
      BRAD PEABODY, DEVELOPER @ TOPTAL
Source: https://www.toptal.com/developers/blog.rss

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#53

Post by dullgiulio »

bogomipz wrote: post #51
dullgiulio wrote: post #47

Earlier quoted context omitted.

There is no watcher: threads get parked by the kernel as "not runnable" while they perform the I/O operation. When the operation is finished, then they become runnable again so the kernel scheduler runs them--that is, it runs the code that comes after the I/O operation. This code (from libuv) notifies the requester that the operation is complete.

Thanks. So is the libuv package implemented as two distinct components then consisting of: 1) The main event loop thread. 2) a thread pool of "workers" which make the actual I/O request and sleep while waiting for the I/O. Then when a "worker" thread is set to runnable again by the kernel(because it's I/O request has been completed)notifies the main event loop thread via a signal? Is that correct?

That's correct, except the notification back is probably via some queue (think of futures or Go channels) rather than signals.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#54

Post by bogomipz »

dullgiulio wrote: post #53
bogomipz wrote: post #51

Earlier quoted context omitted.

Thanks. So is the libuv package implemented as two distinct components then consisting of: 1) The main event loop thread. 2) a thread pool of "workers" which make the actual I/O request and sleep while waiting for the I/O. Then when a "worker" thread is set to runnable again by the kernel(because it's I/O request has been completed)notifies the main event loop thread via a signal? Is that correct?

That's correct, except the notification back is probably via some queue (think of futures or Go channels) rather than signals.

I see that makes sense. Cheers.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#55

Post by glitcher »

justboxing wrote: post #52
glitcher wrote: post #21

Pet peeve: tech articles/blogs which do not prominently display when the article was written. This is the single most important fact I search for before reading time sensitive tech info. I can't tell when this was written, am I missing something?

Yeah, super annoying. They likely have some content marketing campaign that shares old posts at various intervals. Looks like it was published 6 months ago - 'Thu, 11 May 2017 09:14:20 -0400' to be precise. Source: The /rss feed for the blog, which shows the following for this post. Server-side I/O Performance: Node vs. PHP vs. Java vs. Go Understanding the Input/Output (I/O) model of your application can mean the di…

Nice sleuthing! I'm inclined to agree with your assessment about content marketing campaigns being regurgitated over time. Seems they are explicitly choosing to not show the article date in an effort to get more traffic.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#56

Post by justboxing »

glitcher wrote: post #55
justboxing wrote: post #52

Earlier quoted context omitted.

Yeah, super annoying. They likely have some content marketing campaign that shares old posts at various intervals. Looks like it was published 6 months ago - 'Thu, 11 May 2017 09:14:20 -0400' to be precise. Source: The /rss feed for the blog, which shows the following for this post. Server-side I/O Performance: Node vs. PHP vs. Java vs. Go Understanding the Input/Output (I/O) model of your application can mean the di…

Nice sleuthing! I'm inclined to agree with your assessment about content marketing campaigns being regurgitated over time. Seems they are explicitly choosing to not show the article date in an effort to get more traffic.

Thanks. Yes that would be my guess also. They are aggressively marketing their platform here on HN, and even in some of the HN based newsletters.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#57

Post by igouy »

ruffrey wrote: post #35

While still suffering from the problem of benchmarks not reflecting real world performance, The Computer Language Benchmarks Game is an excellent resource. http://benchmarksgame.alioth.debian.org

> … not reflecting real world performance.

Can you show that is true?

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#59

Post by issaria »

amorphid wrote: post #50
issaria wrote: post #31

Earlier quoted context omitted.

Java is compile to bytecode which is then interpreted by a virtual machine, it's not compiled to native code, that's why you cannot distribute Java programs as executable like go.

Is there a way to bundle the JVM (or the parts you need) with the Java app you'd like to run? Erlang (and Elixir) does this with the Erlang VM (BEAM), allowing you to bundle VM+app as a release. The Erlang release must be compiled for the platforms on which that release will be run. It's not quite as elegant as a Go binary, but it's still pretty handy.

Yes, there is a javapackager in java 7 and 8, but with jigsaw that comes with java9, it becomes easier: https://steveperkins.com/using-java-9-modularization-to-ship...
Post reply on HN