2 ms·
"Scale" doesn't mean being able to run many applications on a server - it means being able to serve a lot of traffic. Dynamic languages are inherently slower an
by ninjakeyboard 11y ago
"Scale" doesn't mean being able to run many applications on a server - it means being able to serve a lot of traffic. Dynamic languages are inherently slower and one thread per request server models tend to perform poorly once they hit a certain concurrency threshold because the cost of creating/destroying and context switching between threads becomes pretty high. The reason people talk about node being performant is because it uses a small number of threads with event driven approaches (well, one thread in Javascript itself.)
You'll see a lot of the modern approaches use event driven approaches (Typesafe/Play/Akka/Scala, node, nginx etc) because they handle high levels of concurrency much better than one-thread-per-request models of yester-year. The issue isn't so much one thread per request models as much as it is waiting around for database access etc. Once threads are parked and sleeping, performance will really suffer at scale.
Any use case where you have to read from remote datastores will like topple over pretty quickly or else be very expensive to scale if you're using PHP. The blocking thread-per-request model really doesn't scale very well.
- deleted 11y ago[deleted]
- tyingq 11y agoThis makes sense, but isn't really about PHP at all. You're comparing node.js, with it's built-in event driven web server to ANY language running in a fastcgi or mod_xxx fashion. Python, perl, etc, running under fastcgi would all have the same downsides you are citing. You can, for example, use Facebook's HHVM+Proxygen to serve up event driven PHP. That would be a more direct comparison to node.