Re: Using an APC-lite in a GCI / SuPHP environment
| From: | Terry Ellison | Date: | Thu, 27 Sep 2012 16:25:21 +0000 |
| Subject: | Re: Using an APC-lite in a GCI / SuPHP environment | ||
| References: | 1 2 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-9856@lists.php.net to get a copy of this message | ||
On 27/09/12 16:44, Rasmus Lerdorf wrote:
That was quite a long message. But that's because it's a complex subject :-?
I still don't believe in CGI-based setups. It will be extremely painful to build what you propose. I think a better option would be to look at php-fpm and figure out what is missing from that to use it in a shared hosting environment. It already supports APC and per-user process pools. The only missing piece is probably related to spinning up pools on demand as opposed to starting them all on server start. Surely what counts here are the usage numbers for the different PHP template types, and unfortunately GCI-based setups currently win hands-down on these numbers. Only a limited number of shared hosting providers currently offer a FastCGI alternative and that's for "premium accounts". I don't think that we could coerce this market sector into any technical solution just yet as, though I agree with you that a robust and standard infrastructure template for php-fpm with on-demand spin of user-based pool preferably with optional apc_bin_dump/load of caches to implement some cross-pool persistence would be good. My objective is to improve PHP performance materially for application implementers.Since I am offering to do this extension work myself, then surely any pain is only my problem here -- except of course should the community feel that the implementation isn't up to acceptable standards. Yes there are technical issues, IMO mainly due to the non-PIC nature of the PHP opcoding scheme. However, you already address these relocation issues in your apc_copy_* processes and the swizzling that you do for apc_bin_dump/load. At it's simplest, this LPC does per module apc_bin_dump/load direct into the running PHP thread/process from a per-script NFS-efficient cdb-style repository of modules. Most apps go through one of a limited number of code paths (per script request) as for as module loading is concerned, so the cache add order is highly serially correlated to subsequent read orders. A largely serial read of a single file from an NFS-mounted NAS filesystem is an order faster than marshalling/compiling source from a 100 individual PHP files. What I am proposing is that I do the work, then we review the timings and decide the pros and cons based on the evidence. If they aren't what I anticipate then my work is wasted. If they are, then why not make the extension or some productionised derivative available? The only people who might get upset are the server suppliers. Terry