Can anyone *really* explain opcode caching with PHP?

Server NGINX
1

Hi folks

Thinking of abandoning mod_php for the wonderful world of nginx, but
googling the issue of opcode caching with fastcgi is proving
surprisingly confusing: there’s a lot of conflicting information out
there.

My basic question is this: what is the most performant,
memory-efficient, Slashdot resistant way to set up nginx for running a
complex PHP app?

More specifically:

  1. Why cache? I understood that a fastcgi process compiles the app into
    memory, and serves it from there till it’s recycled after max_requests.
    So what’s the value of opcode caching? To speed up one request in 500?
    But I’ve seen benchmarks that claim an opcode cache with nginx offers
    50% savings on memory and response time. Where would these savings be
    coming from? No one explains…

  2. What cache? Nginx/PHP setup tutorials either omit opcode caching or
    recommend xcache, without explaining why. There’s a lot of conflicting
    information about whether each process needs its own cache (very memory
    intensive?) or whether processes can share a cache. Some bloggers claim
    that Xcache handles this better than APC, but again, no one explains how
    or why. Can anyone offer an authoritative answer to this?

So is opcode caching effective with fastcgi? If so, how does it work,
and what setup plays best with nginx? I would be more than grateful if
anyone can make sense of this. Also, can I please suggest this as a
candidate for the nginx FAQs? Judging by what I’ve been reading, I’m not
the only one who’se confused by this…

Posted at Nginx Forum:

2

Hi folks

Thinking of abandoning mod_php for the wonderful world of nginx, but
googling the issue of opcode caching with fastcgi is proving
surprisingly confusing: there’s a lot of conflicting information out
there.

My basic question is this: what is the most performant,
memory-efficient, Slashdot resistant way to set up nginx for running a
complex PHP app?

You have to take in account one fundamental point:

mod_php is often see as “easy” because it get the apache’s adaptive
process spawning. That means you have not to take in account how much
processes to dedicate to php requests. Apache will spawn processes on
demand.

With nginx you have a proxy talking to a set of processes (via various
protocols). The default php fastcgi server does not have adaptive
process
spawning, so you have to preallocate them, carefully choosing the
number.

This often smashes even experienced apache “sysadmin”, used to not care
that aspect. (i remember one guy working on one of fortune 500 company
blaming nginx on that list). I still have customer (experienced php
developers) that still not get the “multiprocess” concept.

I answer your questions below

More specifically:

  1. Why cache? I understood that a fastcgi process compiles the app into
    memory, and serves it from there till it’s recycled after max_requests.
    So what’s the value of opcode caching? To speed up one request in 500?
    But I’ve seen benchmarks that claim an opcode cache with nginx offers
    50% savings on memory and response time. Where would these savings be
    coming from? No one explains…

fastcgi is only a communication protocol from nginx to your app (the php
server). I am not a big fan of opcode caching, but i can assure you that
it works in php fastcgi server, php-fpm and uWSGI. It really works
whenever your php processes are not recycled (that is why it will never
works on CGI mode)

anyone can make sense of this. Also, can I please suggest this as a
candidate for the nginx FAQs? Judging by what I’ve been reading, I’m not
the only one who’se confused by this…

again, caching fully works whenever you do not recycle your processes,
so
you will not have problems with that.

I only suggest you to choose a more advanced server, like php-fpm or
uWSGI
(even if it is very new in the php world),
as the old-style embedded php fastcgi-server has very few features
(read:
none)

–
Roberto De Ioris
http://unbit.it

3

Am Wed, 7 Mar 2012 10:46:23 +0100
schrieb “Roberto De Ioris” [email protected]:

I only suggest you to choose a more advanced server, like php-fpm or
uWSGI (even if it is very new in the php world),
as the old-style embedded php fastcgi-server has very few features
(read: none)

Additionally, one has to take into account that opcode-caching and the
like that zend, apc etc. do only usually gives you a couple of percents
of increased performance.

When you get “slashdotted”, that is basically useless.

What you have to do is aggressive output-caching via varnish or nginx
(we haven’t done this, yet, but I assume it’s possible since some time,
too).

That will give you much (x-times) more performance than an opcode-cache
will ever be able to.

Rainer

4

Hi Volodymyr

Thanks for your helpful response. From what you say, opcode caching is
essential and Xcache is the way to go.

But just to understand - does a php-fpm pool access a single Xcache, or
is there a separate cache set up for each process? I’m trying to get a
handle on the memory implications.

Thanks for the heads up on uWSGI. But my sysadmin skills are basic (I’m
a developer really) and it looks a bit scary. There’s not much info out
there, while fastcgi is supported in the php core. For someone who is
not a proper sysadmin, is uWSGI, in its present state of development,
really a sensible way to go?

Posted at Nginx Forum:

5

Roberto

I am not a big fan of opcode caching

I’m interested in your reasons for this. My experience with mod_php is
that I get huge performance improvements with opcode caching (my app
loads a lot of code and libraries). If you don’t use opcode caching, is
there a better way to get the same benefits?

Your answer, is my reason :slight_smile: It is app-dependent, so i never blindly
suggest to someone using it, without a proper undestanding of the
system.

Often i have seen badly configured apache server exposing the cached
files
to all the users of the system and so on. I see it as a second step in
building an infrastructure. Having said that, i prefer having an
additional layer (like nginx caching or varnish, as already suggested)
in
front of the apps. …But you can obviously have opcode and caching both
working on the same app :slight_smile:

–
Roberto De Ioris
http://unbit.it

6

Roberto

I am not a big fan of opcode caching

I’m interested in your reasons for this. My experience with mod_php is
that I get huge performance improvements with opcode caching (my app
loads a lot of code and libraries). If you don’t use opcode caching, is
there a better way to get the same benefits?

Posted at Nginx Forum:

7

Thanks for the heads up on uWSGI. But my sysadmin skills are basic (I’m
a developer really) and it looks a bit scary. There’s not much info out
there, while fastcgi is supported in the php core. For someone who is
not a proper sysadmin, is uWSGI, in its present state of development,
really a sensible way to go?

php-fpm (far better that the fastcgi embedded server) is in the core
from
a couple of php releases (even if not compiled-in by default and
somewhere
marked as experimental) but you will find tons of users of it.

uWSGI got proper php support from a couple of weeks, but it has the
advantage in having years of python/perl/lua hosting, so it has a very
solid core. Is its php plugin stable ? I would be a fool in saying that
after only two weeks, but i suggest you to maintain an eye on it :slight_smile:

–
Roberto De Ioris
http://unbit.it

8

Hi guys

You’ve been brilliant - so for now I go with php-fpm and xcache, and I
actually understand what’s happening!

As I say, the community might consider adding this info to the FAQs, as
there’s a lot of misleading blogs and post out there on this whole issue
of fastcgi and opcode caching…

Thanks for all your help!

Posted at Nginx Forum: