On 11/9/2012 9:21 AM, Dan wrote: > 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. My experience has been that FastCGI is definitely slower, but 60% seems to be a considerable variance. The difference I've observed is more like 20%, but performance variances are often largely server configuration and application specific. I recommend reading through http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/ if you haven't already, and ensuring that APC is, in fact, effective. Also, my understanding is that using APC in such a configuration is very RAM-intensive, as there is a dedicated cache for each user. In fact, you may be interested in the same author's benchmarking and performance follow-up article: http://www.brandonturner.net/blog/2009/07/fastcgi_php_opcode_cache_benchmarks/ Disclaimer: I'm in no way affiliated with brandonturner.net; I just found the articles useful in my own work. I'm sure that many of us would be curious to hear back from you once you've tinkered a bit more. Good luck! -Ben > 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.danno@xxxxxxxxx > <mailto:random.danno@xxxxxxxxx>> 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.butler@xxxxxxxxxx > <mailto:noel.butler@xxxxxxxxxx>> 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. >> > > :) > > > 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? > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|