Can anyone *really* explain opcode caching with PHP?
Roberto De Ioris
roberto at unbit.it
Wed Mar 7 09:46:23 UTC 2012
> 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)
>
> 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...
>
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
More information about the nginx
mailing list