Mar
2
Currently I’m facing some issues getting PHP-FPM/FastCGI functioning properly with Apache 2.4.
mod_fastcgi no longer compiles properly, resulting in numerous errors such as the following;
mod_fastcgi.c:1413: error: request for member ‘log’ in something not a structure or union
mod_fastcgi.c:1413: error: request for member ‘connection’ in something not a structure or union
mod_fastcgi.c:1413: error: request for member ‘server’ in something not a structure or union
There are alternative PHP-FPM solutions using ProxyPass, however there are issues with static files and mod_rewrite breaks URL variable passing. Despite the issues, these two methods do actually get PHP-FPM to function.
mod_proxy
ProxyPass / fcgi://127.0.0.1:9000/www/
ProxyErrorOverride on
mod_rewrite:RewriteEngine On
RewriteRule ^/?(.*\.php)$ fcgi://127.0.0.1:9000/www/$1 [P,L]
There is an alternative to mod_fastcgi named mod_fastcgi_handler which compiles properly, but does not seem to properly connect to PHP-FPM. No errors turn up in PHP-FPM, but this does show up in Apache’s error_log.
(104)Connection reset by peer: [client x:63661] FastCGI: failed to write to backend server (id=4)
I will update this post as a solution is found.
*UPDATE MARCH 4*
Found a simple fix, adjust the ending URL for each VirtualHost and PHP-FPM works great. 
ProxyPassMatch ^(.*\.php)$ fcgi://127.0.0.1:9000/www$1
*UPDATE MARCH 5*
Apparently ProxyPassMatch does not work very well inside virtualhosts, giving 404 errors for the same request URL.
(Apache 2.4.x bug?) A user on Apache’s mailing list gave me a suggestion to try using LocationMatch, and it worked great, so here it is.
<LocationMatch ^(.*\.php)$>
ProxyPass fcgi://127.0.0.1:9000/www
</LocationMatch>
*UPDATE MARCH 10*
If you prefer to use the old method of using mod_fastcgi, a user on has GitHub modified it to compile properly on Apache 2.4. (Link)
Mar 2, 2012 / Web Development / By Daniel / 7 Comments
Feb
22
Seven years after their last major update, 2.2, the Apache Software Foundation released a new version, 2.4. It boasts many new features as well as better performance, and lower memory usage; one of the main reasons people are starting to move away from Apache to Nginx. Check out the changelog here, and download it here.
One thing I’ve noticed is that mpm_event is no longer categorized as experimental, which should help slightly against slowloris attacks. I’ve also been working on a post comparing performance and memory usage between the different apache mpm’s, but I’ll have to redo that since 2.4 is now released.
I’m currently configuring a new setup of CentOS 6, Apache 2.4, PHP-FPM, and MariaDB on my alt server at http://cookie.danielhe.com/, and then I’ll be transferring the current site to that server, and use this one as a backup. I’ve had some issues setting it up, so I have made a post detailing the issues and solution for configuring Apache 2.4 and PHP-FPM here.
Feb 22, 2012 / Web Performance / By Daniel / 2 Comments
Jan
26
Since most people only use .htaccess files for their top level directory, by disabling .htaccess files in subdirectories you can get a nice performance boost of anywhere from 10% upwards to 100%. This would be since Apache would have to check every single folder for a .htaccess; if a user requests /folder/files/file.html, Apache checks /folder and /folder/files for every single request. In the case of a low traffic website, there won’t be any visible difference, but it does improve your overall connections per second, useful for a high traffic website, or if you’re just benchmark obsessed. (Benchmarks from catn)
Assuming your virtual directory structure is something similar to /home/user/public_html, just add the following to your httpd.conf to disable checking for .htaccess files anywhere other than your public_html folder.
<Directory /home/*/*/*>
AllowOverride None
</Directory>
Jan 26, 2012 / Web Performance / By Daniel / No Comments
Jan
20
A couple of days ago, I setup CloudFlare on this blog. Although the site was already quite fast, I had heard many good things about CloudFlare, and wanted to see what it could do to this site.
First of all,
What is CloudFlare?
CloudFlare is a free CDN, with a paid $20 /mo service as well, which reduces your site load time by caching static files (images, CSS, etc) on their numerous datacenters world wide, and then using Anycast to serve the files from the closest location to your visitor. They claim to have a 40% average performance boost. CloudFlare also offers spam, attack, and DDOS protection, for free. The infamous LulzSec used this service to protect their website, so the claimed protection is most likely real.
After finding out what the service was, I thought that I would not need it, since my blog already loads in under a second from Atlantic Canada, and in under 500 ms in New York. But, since I like trying everything, I decided to try them out for a bit anyways.
The transfer over to CloudFlare was easy, I copied my DNS zones over, and switched my nameservers to theirs through my domain registrar. This took about 30 seconds of work and half an hour of waiting, since 1and1 is incredibly slow.
After my domain’s DNS updated, I cleared my DNS and browser cache, and tested out the speed of my site. It ‘seemed’ to load faster, images appeared to load concurrently rather than after another, but Pingdom tests took around the same time, likely due to the fact their DNS cache was not updated. I was slightly disappointed, but I decided to keep it anyways, since it would offload some work off my puny VPS, and since you are supposed to wait a bit for CloudFlare’s cache to build up first before any major changes.
A couple days later, I tested my sites in a non-scientific fashion, and they seemed maybe a ‘hair’ faster, but I was a bit surprised by my Pingdom results.
Load Times Before:
- From New York: 375 – 490 ms
- From Dallas: 1.1 – 1.5 seconds
Load Times After:
- From New York: 195 – 300 ms
- From Dallas: 550 – 800 ms
The differences are minuscule in real life, but CloudFlare’s 40% claim IS accurate. I’m not quite sure how it’s able to make such a big (small?) difference in New York, since the physical location of my server is in New York, but it is indeed faster.
In my opinion, CloudFlare gets a yay. 
Jan 20, 2012 / Web Performance / By Daniel / 1 Comment
2,049 Followers
Fllw
126 Fans
Like