httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Johnson <...@indietorrent.org>
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

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@gmail.com
> <mailto:random.danno@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.butler@ausics.net
>     <mailto:noel.butler@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.
>>
> 
>         :)
> 
> 
>         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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message