4 ms·

Dude, what are you rambling about? The same can be achieved in Apache with 2 config lines. Nginx has taken over some of Apache's market because it's lighter on

by Nux 13y ago

Dude, what are you rambling about? The same can be achieved in Apache with 2 config lines. Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff. Regarding functionality and configuration there is not much difference, actually I think Apache still has the edge here.

oakaz 13y ago
Let's consider boxcars also: http://github.com/azer/boxcars http://github.com/azer/boxcars
rehack 13y ago
>Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff. That's precisely why we moved to Nginx. We do mostly Java so Apache was not the problem there, as it was simply proxying over to Jettys. But the blog is wordpress that means PHP, so we had to use modphp modules with Apache. That was Okay initially, but as we scaled, we saw some 50 instances of Apache and each taking 25 Mb memory. And note, most of the bloat in memory was due to modphp being loaded in-memory in each instance. We moved to Nginx with an external php-fpm for PHP, and just 4 Nginx instances take up the entire load and each uses some 2.5 Mb of memory. And at the same time Google webmaster shows a significant drop in average latency. So that's our experience of why we moved to Nginx. Edit: typo
- thwarted 13y ago
  So you've moved the memory usage from the web server proper to the external php-fpm processes, which are most likely getting recycled more frequently than the default settings for apache prefork workers are so you're not seeing the ballooning PHP memory usage. The size of the 50 instances of Apache each taking 25 meg is most likely because of the PHP code and mod_php, not because of Apache itself.
  - rehack 13y ago
    Agreed. In hindsight, I am sure, we could have externalized the PHP with Apache as well. But the larger context of this move was doing more with less. And Nginx just working with 4 instances and serving just as much, with a reduced average latency of page load, justified the move. And I sort of felt sad doing this. Because I have a huge respect for Apache. I hope just like what Chrome did to Firefox, Nginx does to Apache, and its a win-win for all.
    - thwarted 13y ago
      But the larger context of this move was doing more with less. And Nginx just working with 4 instances and serving just as much, with a reduced average latency of page load, justified the move. "More with less" here is a judgement call. You've increased the number of processes and subsystems that need to be managed (nginx + php_fpm), which is more. You've increased the context switching when dynamic requests need to be passed to another process and proxied through nginx. The communication between the frontend web server and php_fpm needs to be serialized in some fashion, so you're now incurring a greater than 1x cost in processing and parsing things like HTTP headers and the request (serializing and deserializing the data to pass that between the processes). It seems you're ignoring the actual cost of running dynamic PHP code because the cost has been moved out of the "web server", the thing that listens on port 80, and into something that isn't considered "a web server", but this is just a change in bookkeeping. Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be running/serving PHP in apache? If so, you can do the same thing by offloading all your static asset serving to another server (or a completely external CDN, which has other extremely beneficial client-side advantages too) using apache too. That is, the choice of software here isn't as big a win as presented, it's the architecture of the ecosystem that is the big influence. It's great that you found something that works better for your workload, and it's appropriate to use what works and not get bogged down in why all the time. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap.
      - 13y ago
- xist 13y ago
  I hear this a lot about Apache and there's one thing I'm not sure a lot of people understand... it's SHARED memory in most cases. While it spawns several processes (depending on which worker method), it's not as awful as it looks at first glance. A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consumption/index.shtml http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump... there's probably better examples. Yes nginx does have lower memory usage, but on most non vps/shared servers this is a lot less of a concern than most people think vs Apache. php-fm works great with Apache as well and probably accounts for the huge resource gain over mod_php that Apache uses by default.
  - thwarted 13y ago
    I hear this a lot about Apache and there's one thing I'm not sure a lot of people understand... it's SHARED memory in most cases. While it spawns several processes (depending on which worker method), it's not as awful as it looks at first glance. Apache, and specifically mod_php, doesn't have that level of control over memory usage (mod_perl (and, incidentally, mod_python) has deeper integration with Apache to encourage, with the right configuration, more of the memory to be shared between processes, but it's still not that great). The Apache parent process, primarily exists to do process, signal, and socket management, it's not really possible to do a lot of application level (pre)processing before subprocesses are forked off, which is what would be required to share a significant portion of the address space. If you have a .php file run via mod_php that looks like this: $x=""; for ($a=0;$a<(1024*1024*100);$a++) { $x.="1"; } This will produce 100MB of non-shared memory in a child process, when the request is made and serviced by that child. And, because of the way requests are dispatched to children, at a low request rate the same child could end up serving all (or a majority of) requests. This unbalances the memory usage between processes. A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump.. http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump.... there's probably better examples. That is a great link in general for how shared memory and COW works.

by Nux 13y ago

oakaz 13y ago

Let's consider boxcars also: http://github.com/azer/boxcars http://github.com/azer/boxcars

rehack 13y ago

>Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff. That's precisely why we moved to Nginx. We do mostly Java so Apache was not the problem there, as it was simply proxying over to Jettys. But the blog is wordpress that means PHP, so we had to use modphp modules with Apache. That was Okay initially, but as we scaled, we saw some 50 instances of Apache and each taking 25 Mb memory. And note, most of the bloat in memory was due to modphp being loaded in-memory in each instance. We moved to Nginx with an external php-fpm for PHP, and just 4 Nginx instances take up the entire load and each uses some 2.5 Mb of memory. And at the same time Google webmaster shows a significant drop in average latency. So that's our experience of why we moved to Nginx. Edit: typo

thwarted 13y ago
So you've moved the memory usage from the web server proper to the external php-fpm processes, which are most likely getting recycled more frequently than the default settings for apache prefork workers are so you're not seeing the ballooning PHP memory usage. The size of the 50 instances of Apache each taking 25 meg is most likely because of the PHP code and mod_php, not because of Apache itself.
- rehack 13y ago
  Agreed. In hindsight, I am sure, we could have externalized the PHP with Apache as well. But the larger context of this move was doing more with less. And Nginx just working with 4 instances and serving just as much, with a reduced average latency of page load, justified the move. And I sort of felt sad doing this. Because I have a huge respect for Apache. I hope just like what Chrome did to Firefox, Nginx does to Apache, and its a win-win for all.
  - thwarted 13y ago
    But the larger context of this move was doing more with less. And Nginx just working with 4 instances and serving just as much, with a reduced average latency of page load, justified the move. "More with less" here is a judgement call. You've increased the number of processes and subsystems that need to be managed (nginx + php_fpm), which is more. You've increased the context switching when dynamic requests need to be passed to another process and proxied through nginx. The communication between the frontend web server and php_fpm needs to be serialized in some fashion, so you're now incurring a greater than 1x cost in processing and parsing things like HTTP headers and the request (serializing and deserializing the data to pass that between the processes). It seems you're ignoring the actual cost of running dynamic PHP code because the cost has been moved out of the "web server", the thing that listens on port 80, and into something that isn't considered "a web server", but this is just a change in bookkeeping. Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be running/serving PHP in apache? If so, you can do the same thing by offloading all your static asset serving to another server (or a completely external CDN, which has other extremely beneficial client-side advantages too) using apache too. That is, the choice of software here isn't as big a win as presented, it's the architecture of the ecosystem that is the big influence. It's great that you found something that works better for your workload, and it's appropriate to use what works and not get bogged down in why all the time. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap.
    - 13y ago
xist 13y ago
I hear this a lot about Apache and there's one thing I'm not sure a lot of people understand... it's SHARED memory in most cases. While it spawns several processes (depending on which worker method), it's not as awful as it looks at first glance. A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consumption/index.shtml http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump... there's probably better examples. Yes nginx does have lower memory usage, but on most non vps/shared servers this is a lot less of a concern than most people think vs Apache. php-fm works great with Apache as well and probably accounts for the huge resource gain over mod_php that Apache uses by default.
- thwarted 13y ago
  I hear this a lot about Apache and there's one thing I'm not sure a lot of people understand... it's SHARED memory in most cases. While it spawns several processes (depending on which worker method), it's not as awful as it looks at first glance. Apache, and specifically mod_php, doesn't have that level of control over memory usage (mod_perl (and, incidentally, mod_python) has deeper integration with Apache to encourage, with the right configuration, more of the memory to be shared between processes, but it's still not that great). The Apache parent process, primarily exists to do process, signal, and socket management, it's not really possible to do a lot of application level (pre)processing before subprocesses are forked off, which is what would be required to share a significant portion of the address space. If you have a .php file run via mod_php that looks like this: $x=""; for ($a=0;$a<(1024*1024*100);$a++) { $x.="1"; } This will produce 100MB of non-shared memory in a child process, when the request is made and serviced by that child. And, because of the way requests are dispatched to children, at a low request rate the same child could end up serving all (or a majority of) requests. This unbalances the memory usage between processes. A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump.. http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump.... there's probably better examples. That is a great link in general for how shared memory and COW works.