"For starters, with mod_php, each request that Apache handles loads PHP - and all of it’s libraries."
No, it doesn't. In fact, that's a distinct advantage of mod_php. Everything is loaded and in memory when the request comes in. Throw APC on top of that and your code is also already compiled.
The only way that would not be true is if you've got MaxRequestsPerChild tuned really low and are restarted Apache children constantly. Some restarting is OK and helps keep memory leaks under control, but it shouldn't be so low that nothing stays cached. It's going to be slow with or without PHP running as a FastCGI.
Of course, I don't know how NGINX handles things, but for Apache he's got it all wrong.
"In fact, that's a distinct advantage of mod_php. Everything is loaded and in memory when the request comes in. Throw APC on top of that and your code is also already compiled."
I would love it if someone cleared a very basic doubt of mine : If php is compiled, then what is the advantage of other programming languages? Wouldn't it be the same as anything else (except maybe considering the size of the language)? Is it just the optimization of the compiler then? And if so, would PHP compare the same to other loosely typed languages?
If PHP is compiled, then it still has almost the same benefits and drawbacks compared to all the other languages, except for one: once it's compiled, PHP runs faster than it does when interpreted. Simple.
IIRC the compiler for PHP uses a scheme compiler as a backend.
Let's say you write a Python program that outputs Javascript. It could be considered a "compiler". Or let's say that you write your own language, which outputs to other 3 or 4... there's also compiling involved. A compiler doesn't need to output assembler. Even if every compiler did that, features of the language would result in different execution code.
For example, PHP's variables can be a string of any size, or a number, or an object, and you can change its type while the program is running. The compiler doesn't optimize the code execution as easy as, say, in Java. You can not allocated the minimum amount of memory that will store the variable values, for example.
"No, it doesn't. In fact, that's a distinct advantage of mod_php. Everything is loaded and in memory when the request comes in."
Actually, thats not right, even with APC. A large set of operations run at the start of every request. For example, the class- and function-tables are filled and copied. Each extension (library) also has a per-request callback.
I don't know anything about NGINX either. But he's not wrong about the "epic shit ton of overhead".
* Make sure that your init script is actually working. The init script you posted a link to places the pid file in a different location than the default for a source compiled nginx.
Some commenters recommended Nginx to me a while back. It freaking rocks. It was such a breeze to setup and the memory usage is incredibly low and stable. Thanks for the tips then, and thanks for continuing to post articles to spread the word!
I generally agree with the advice in this article, excluding the bit about "each request that Apache handles loads PHP". nginx is glorious software, and the combination of nginx / fastcgi / and APC work very well. At Wikispaces we serve over ten million PHP requests a day using a similar setup.
However, this article implies nginx is better than Apache for the wrong reasons. nginx has two critical advantages over Apache in this context:
- handling dynamic requests without tying up backends (buffering proxy server)
- serving of static files from disk without incremental memory use (event-driven vs. multi-thread or multi-process)
It may also be the case that nginx is marginally faster than Apache in pushing bits absent of these two issues, but in my opinion gains here are greatly outweighed by operational considerations (see below). I'd modify this article's advice to be:
1. serve all static requests using an event-driven webserver (nginx)
2. proxy all dynamic requests through a server that buffers backend results and spoonfeeds clients (nginx)
3. wrap your backend scripting or application server in the system that is easiest to understand, deploy, maintain, and troubleshoot (Apache and mod_php)
There are other choices here that may be as good or better in your environment, but with 1. and 2. in place, CPU/memory/IO savings by rejiggering 3. are minimal.
Operational Considerations: including but not limited to process management, logging, availability of value-add modules like mod_security, over-the-wire troubleshooting, HTTP load-balancing, and finally non-rarity of your solution. If plain fastcgi is a few percent faster than mod_php but orders of magnitude more rare, I'd happily forego the performance gain for the benefits of a larger install base.
After having Apache die to a memory-related config problem again this week, after having to reinstall it from source to fix an issue with PHP's mail() library, I am reminded once again how much I love Nginx's rock-solid performance.
I've been using this setup, except with XCache instead of APC. Does anyone know enough about the differences between the two to say if this is better or worse?
"For starters, with mod_php, each request that Apache handles loads PHP - and all of it’s libraries."
No, it doesn't. In fact, that's a distinct advantage of mod_php. Everything is loaded and in memory when the request comes in. Throw APC on top of that and your code is also already compiled.
The only way that would not be true is if you've got MaxRequestsPerChild tuned really low and are restarted Apache children constantly. Some restarting is OK and helps keep memory leaks under control, but it shouldn't be so low that nothing stays cached. It's going to be slow with or without PHP running as a FastCGI.
Of course, I don't know how NGINX handles things, but for Apache he's got it all wrong.