From owner-freebsd-questions@FreeBSD.ORG Fri May 7 20:57:25 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A865D106566B for ; Fri, 7 May 2010 20:57:25 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 363168FC08 for ; Fri, 7 May 2010 20:57:25 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OAUbn-0001r3-QP for freebsd-questions@freebsd.org; Fri, 07 May 2010 22:57:19 +0200 Received: from pool-70-21-1-190.res.east.verizon.net ([70.21.1.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 May 2010 22:57:19 +0200 Received: from nightrecon by pool-70-21-1-190.res.east.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 May 2010 22:57:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org connect(): No such file or directory From: Michael Powell Followup-To: gmane.os.freebsd.questions Date: Fri, 07 May 2010 16:56:32 -0400 Lines: 125 Message-ID: References: <4BE472EC.5060808@netmusician.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-70-21-1-190.res.east.verizon.net Subject: Re: php-cgi 5.3.x and APC 3.1.3 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 20:57:25 -0000 Joe Auty wrote: > Hello, > > I'm trying to get the APC user cache to work for me... It works with PHP > installed as an Apache module, but not as a CGI. I run Apache with the event mpm. This may, or may not be wise, but I've been doing it for a while now and had no problems with it. I also use Xcache so my comments are not APC specific. Since not all of PHP is considered thread safe it is not advisable to run PHP on the event mpm as it is a threaded version. The way around this is to not use mod_php but instead run mod_fcgid.so so PHP can be run as a FastCGI. > I understand that in order to get this to work one has to add a: > >> FastCgiConfig -maxClassProcesses 1 > > to their Apache config (for those that use Apache). I've done this, but > I'm still not seeing any evidence that the user cache is working. This I do not know about and have never seen, but I do recall floundering around in the beginning and being very confused by the difference between exec'ing PHP code as a CGI as opposed to running it in a FastCGI process. There is a huge difference, with the FastCGI being many times faster. > The reason why I'm writing to this list rather than a PHP list is > because I'm a little confused by some of the PHP install options. It > looks like in 5.2 there was a FastCGI compile option. I'm assuming this > is enabled by default in 5.3? Not sure about what is in the default config, I'd have to look. But to use what I've described above you do not need to build/install mod_php, or have it in the LoadModule section of httpd.conf. But you do need to build PHP with CGI and CLI support. I have mod_fcgid.so in the LoadModule directives section of my httpd.conf. See the part below about "connecting" Apache to a "long running" PHP process. >> # php-cgi -v >> PHP 5.3.2 with Suhosin-Patch (cgi-fcgi) (built: May 7 2010 12:53:07) >> Copyright (c) 1997-2009 The PHP Group >> Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies > > What's confusing is the existence of both mod_fastcgi and mod_fcgi. Is > PHP compiled against fastcgi or fcgi? It looks like the former is > required for my setup. Since the key ingredient to this is the > FastCgiConfig directive above, I'm not sure if there is a way to test > that this directive has been recognized? I'm not seeing it in my > phpinfo() screens... Could I have mod_fcgi built into php-cgi and this > FastCGI Apache directive is being ignored? IIRC correctly, the mod_fastcgi became deprecated when the Apache Foundation took over and imported the mod_fcgi codebase into the Apache project. Not totally sure, but this is what I seem to think I remember. But neither mod_fastcgi nor mod_fcgi get built into php-cgi, to reuse your terminology. These are Apache server modules designed to connect the Apache server to a different process running outside and separate from Apache. The module is just a gateway for connecting to the PHP FastCGI process. When you execute php -v as a CLI, it runs, returns the info, and exits. The difference between this and a FastCGI process is the FastCGI is what is known as a "long running process". It starts the PHP interpreter as well as loading any PHP modules specified in extensions.ini, but it does not exit or "end", but continues to run. The advantage of this is it does not waste resource overhead creating and destroying interpreters to run each piece of PHP code that comes along. > In case this is relevant, I'm not doing any suexec stuff just yet. > Me, I would try and avoid suexec whenever/wherever possible. It is very slow. At any rate, this stuff is *very* confusing. So this example from a working Apache running the event mpm and PHP as a FastCGI. In addition to the LoadModule line mentioned above there is also the following: [...other stuff here...] # added for mod_fcgid #SetHandler fcgid-script FCGIWrapper /usr/local/bin/php-cgi .php Options ExecCGI # end of mod_fcgid change # added to enable mod_fcgid AddHandler fcgid-script .fcgi .php SocketPath /var/run/fcgidsock/ IPCConnectTimeout 10 IPCCommTimeout 20 OutputBufferSize 0 MaxRequestsPerProcess 500 In phpinfo(); you can see this: Server API CGI/FastCGI My options for PHP build: WITH_CLI=true WITH_CGI=true WITH_APACHE=true WITHOUT_DEBUG=true WITH_SUHOSIN=true WITH_MULTIBYTE=true WITHOUT_IPV6=true WITHOUT_MAILHEAD=true WITH_REDIRECT=true WITH_DISCARD=true WITH_FASTCGI=true WITH_PATHINFO=true Also keep in mind that any time PHP is rebuilt APC will need to be rebuilt too. -Mike