Ok folks. I've got this working but performance with mod_fastCGI but I'm disappointed with the results compared to mod_php. I know mod_php is supposed to be the fastest option, but fastcgi is on average 60% slower than mod_php, so I'm hoping someone can verify my configuration.
I added the following to my main config: LoadModule fastcgi_module modules/mod_fastcgi.so > FastCgiWrapper On > FastCgiIpcDir /var/run/fastcgi > FastCgiConfig -idle-timeout 20 -maxClassProcesses 1 > I also added the following to my vhost block: SuexecUserGroup wp-itghome www > DirectoryIndex index.php > AddHandler php5-fastcgi .php > Action php5-fastcgi /cgi-itghome-dev/php-fcgi > ScriptAlias /cgi-itghome-dev "/var/www/cgi-itghome-dev/" > FastCgiServer /var/www/cgi-itghome-dev/php-fcgi -socket > /var/run/fastcgi/fastcgi-itghome-dev.socket -user wp-itghome -group www > -idle-timeout 310 -flush > <Directory "/var/www/cgi-itghome-dev"> > AllowOverride none > Options None > Order allow,deny > Allow from all > </Directory> > <Location /cgi-itghome-dev> > Order Deny,Allow > Deny from All > Allow from env=REDIRECT_STATUS > </Location> > The socket file specified above is owned by apache, and the contents of /var/www/cgi-itghome-dev are all owned by the wp-itghome-dev user and "www" group. Site content loads properly and APC reports it's using the same cache file for every request so it seems to be working. The server in question has a single CPU (3 Ghz) and 2 GB of RAM. I used apache bench to performance-test the VM, having it request phpinfo.php from 100-1000 times, with the test scaling 100 requests at a time and with 100 of those requests concurrent. At peak, this site would reasonably have to accommodate 100 concurrent users, so I figured this was appropriate. The test results with mod_php show an average response time of 1600 ms, and with mod_fastcgi it was almost 4400 ms. Watching top during tests shows a lot of httpd processes waiting for I/O, I assume because of contention for the socket file. To mitigate that I also tried setting fastcgi to listen on a tcp port instead of using a socket file and performance was worse, on average 6000 ms. Can someone tell me whether this performance differential is to be expected? Thanks, Dan On Wed, Nov 7, 2012 at 9:19 AM, Dan <random.da...@gmail.com> wrote: > Thanks Noel. > > We can use VSFTPD for developer access post-install via WordPress, and > could in theory use umask in the apache startup script to set apache's > umask (even though as stated in my OP that it wasn't working), but I'd > rather not set up an FTP daemon and stick with chrooted SFTP access instead. > > I have gotten PHP as a (standard) CGI with the "SuexecUserGroup" directive > working to set the correct ownership on uploaded plugins, but we use APC > (Alternate PHP Cache) as our opcode cache and this doesn't work with > standard PHP-CGI deployments. ApacheBench testing shows an increase of > approximately 1 second response time per request when APC isn't used, so > that's a deal-breaker for me. SuPHP appears to have the same limitation, so > it's not an option either. > > At this time I'm evaluating mod_fastcgi, which supposedly works with > SuExec and APC. If anyone has an input or past-difficulties with this > proposed deployment, I'd appreciate hearing from you. > > Dan > > > > On Fri, Nov 2, 2012 at 10:56 PM, Noel Butler <noel.but...@ausics.net>wrote: > >> ** >> On Fri, 2012-11-02 at 14:31 -0500, Dan wrote: >> >> Ben, >> >> Yes you're right, we are using mod_php, but only because no other >> alternative was required up to this point. >> >> This server hosts many vhosts, and I've read that SuEXEC isn't >> appropriate for multi-site installations of apache. >> >> >> >> suexec is perfect for any number of hosts, but I assume you mean the >> phpsuexec stuff, which you are in fact correct, it, along with suphp, >> introduce serious performance hits if you have more than a few hundred >> vhosts, and given most hosts run a couple of thousands vhosts per typical, >> say DL380 type machine, you will notice it, and your customers will notice >> it - especially if the machine has many busy sites. >> >> thats why most large sites use php admin value flags for locking them >> down, but some php plugins that are poorly written dont always honour >> those restrictions, which is where suhosin comes in to try fill the gap ( >> although I think its mod_php's job to be more anal about what it allows) in >> trying to catch those uselessly written extensions for doing stuff you dont >> want it to, even in this configuration, it wont be 100% secure, but it >> certainly is not 100% secure using other methods either, suphp for instance >> although not too bad in past couple years, has had a poor history in the >> past. >> >> >> >> I'm looking into SuPHP right now, but their site _seems_ to be down. >> >> >> >> [image: :)] >> >> >> setfacl chmod etc are no good, they only set existing, you need to work >> with umasks, it is not possible to have apache set umask in virtualhosts, a >> dirty way would be to set the umask in the init script for httpd, but I >> would not recommend that since allowing httpd to group write access, will >> introduce major security issues for all vhosts. You are better off >> circumventing this via ftp, what ftpd are you using? >> >> >> >
<<face-smile.png>>
