5 ms·

Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?

by jsnk 13y ago

EGreg 13y ago
Yes and no. If Node.js can do things like * cache responses * not send duplicate responses but instead maintain a waiting queue * throttle requests based on # of preforked threads etc. then it would be faster most of the time. And equally importantly you can take a page from Yahoo's book and pre-render stuff on the presumably faster server, for mobile devices and robots.
- rubiquity 13y ago
  Why can't you do these things in PHP (or whatever other language you're already using)?
  - EGreg 13y ago
    You can, but Node.js is often a better choice than PHP. Caching: you can have ONE node.js process listening to all requests, and it can keep the cached info in memory, to be looked up much more quickly. In PHP, you'd have to load the entire script environment, connect to an external source like Memcached or APC, etc. Waitlist: Similar to caching, except Node.js can hold off on responding to the request until the response came back. It's MUCH harder to make something like PHP iterate through the waitlist because a bunch of scripts might get called at once, and the way it works, all of them will have to sleep. With Node.js, only one process has to sleep -- or handles something else while you're waiting. etc.
  - Touche 13y ago
    Because that shouldn't be the responsibility of the business layer. Perhaps they are serving many apps other than just the web client, some of which don't want cached data.
deleted 13y ago
[deleted]
k3n 13y ago
Though there's no absolute answer here, and it could very well go either way, as he explains it would most likely be irrelevant due to the fact that PHP can only process serially. For instance, if you need to run 3 SQL queries in PHP, then the total execution time will be t1 + t2 + t3. On the other hand, if you make those queries in NodeJS instead, it will be MAX(t1, t2, t3). So, it depends on the complexity of your app and your ability to decouple and separate concerns in the NodeJS server.
- anonymoushn 13y ago
  Is it actually impossible to query the DB asynchronously in PHP?
  - k3n 13y ago
    Not impossible, but not easy either considering PHP is single-threaded and synchronous.
    - anonymoushn 13y ago
      I've never heard of languages being synchronous or asynchronous before. It looks like PHP ships with asynchronous DB APIs.
      - k3n 13y ago
        Ok, poor example; just consider that it's single-threaded. Pretty much the only threading support is by way of a young PECL extension called pthreads[1], which is still experimental and dangerous. Otherwise, you can use the PCTL extension[2], if you don't mind compiling PHP yourself (and if you're not on Windows, where it's not supported). 1. http://www.php.net/manual/en/intro.pthreads.php http://www.php.net/manual/en/intro.pthreads.php 2. http://www.php.net/manual/en/pcntl.installation.php http://www.php.net/manual/en/pcntl.installation.php
ChikkaChiChi 13y ago
Node can issue multiple non-blocking commands which can let PHP create children processes to handle each request. It can work, though you lose a bit of transparency.
sisk 13y ago
I think what EGreg is talking about (benefits of using node over, e.g., PHP) and what this article is talking about (benefits of throwing node between the client and the back-end) are kind of two different things. But I think the similarities address what you're asking. If node is being used simply as a proxy then—no question—throwing it in to the mix will simply introduce latency (shortest distance blah blah blah). However the suggesting made by both the article and EGreg seems to be, "use the right tool for the job." In the case of the article, Nicholas seems to be suggesting that aspects of your data model might be better suited in the hands of your front-end engineers as they're the ones presenting that data. EGreg is suggesting leveraging the asynchronous nature of node (and evented programming in general) to handle certain tasks more efficiently. But to answer your question, not necessarily. Even if you introduce additional latency, you might still benefit from putting more of the data model into the hands of your front-end guys (particularly if you're at a massive organization where coordination is the biggest hurdle). Plus, there's nothing stating you can't push the mutations performed at the node layer down farther into your stack and, potentially, remove it entirely. And, there's also the case that node might do the work you've delegated to it more quickly than if it were performed in PHP, negating the loss due to additional latency (but if that additional latency is the concern, I'd recommend relying benchmarking to help you make that decision).

Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?

by jsnk 13y ago

Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?

EGreg 13y ago

Yes and no. If Node.js can do things like * cache responses * not send duplicate responses but instead maintain a waiting queue * throttle requests based on # of preforked threads etc. then it would be faster most of the time. And equally importantly you can take a page from Yahoo's book and pre-render stuff on the presumably faster server, for mobile devices and robots.

rubiquity 13y ago
Why can't you do these things in PHP (or whatever other language you're already using)?
- EGreg 13y ago
  You can, but Node.js is often a better choice than PHP. Caching: you can have ONE node.js process listening to all requests, and it can keep the cached info in memory, to be looked up much more quickly. In PHP, you'd have to load the entire script environment, connect to an external source like Memcached or APC, etc. Waitlist: Similar to caching, except Node.js can hold off on responding to the request until the response came back. It's MUCH harder to make something like PHP iterate through the waitlist because a bunch of scripts might get called at once, and the way it works, all of them will have to sleep. With Node.js, only one process has to sleep -- or handles something else while you're waiting. etc.
- Touche 13y ago
  Because that shouldn't be the responsibility of the business layer. Perhaps they are serving many apps other than just the web client, some of which don't want cached data.

deleted 13y ago

[deleted]

k3n 13y ago

Though there's no absolute answer here, and it could very well go either way, as he explains it would most likely be irrelevant due to the fact that PHP can only process serially. For instance, if you need to run 3 SQL queries in PHP, then the total execution time will be t1 + t2 + t3. On the other hand, if you make those queries in NodeJS instead, it will be MAX(t1, t2, t3). So, it depends on the complexity of your app and your ability to decouple and separate concerns in the NodeJS server.

anonymoushn 13y ago
Is it actually impossible to query the DB asynchronously in PHP?
- k3n 13y ago
  Not impossible, but not easy either considering PHP is single-threaded and synchronous.
  - anonymoushn 13y ago
    I've never heard of languages being synchronous or asynchronous before. It looks like PHP ships with asynchronous DB APIs.
    - k3n 13y ago
      Ok, poor example; just consider that it's single-threaded. Pretty much the only threading support is by way of a young PECL extension called pthreads[1], which is still experimental and dangerous. Otherwise, you can use the PCTL extension[2], if you don't mind compiling PHP yourself (and if you're not on Windows, where it's not supported). 1. http://www.php.net/manual/en/intro.pthreads.php http://www.php.net/manual/en/intro.pthreads.php 2. http://www.php.net/manual/en/pcntl.installation.php http://www.php.net/manual/en/pcntl.installation.php

ChikkaChiChi 13y ago

Node can issue multiple non-blocking commands which can let PHP create children processes to handle each request. It can work, though you lose a bit of transparency.

sisk 13y ago

I think what EGreg is talking about (benefits of using node over, e.g., PHP) and what this article is talking about (benefits of throwing node between the client and the back-end) are kind of two different things. But I think the similarities address what you're asking. If node is being used simply as a proxy then—no question—throwing it in to the mix will simply introduce latency (shortest distance blah blah blah). However the suggesting made by both the article and EGreg seems to be, "use the right tool for the job." In the case of the article, Nicholas seems to be suggesting that aspects of your data model might be better suited in the hands of your front-end engineers as they're the ones presenting that data. EGreg is suggesting leveraging the asynchronous nature of node (and evented programming in general) to handle certain tasks more efficiently. But to answer your question, not necessarily. Even if you introduce additional latency, you might still benefit from putting more of the data model into the hands of your front-end guys (particularly if you're at a massive organization where coordination is the biggest hurdle). Plus, there's nothing stating you can't push the mutations performed at the node layer down farther into your stack and, potentially, remove it entirely. And, there's also the case that node might do the work you've delegated to it more quickly than if it were performed in PHP, negating the loss due to additional latency (but if that additional latency is the concern, I'd recommend relying benchmarking to help you make that decision).