httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Johnson <>
Subject Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Date Fri, 09 Nov 2012 15:47:26 GMT

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

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:

Disclaimer: I'm in no way affiliated with; 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!


> I added the following to my main config:
>     LoadModule fastcgi_module modules/
>     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 <
> <>> 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 <
>     <>> 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:
For additional commands, e-mail:

View raw message