I’ve found a couple useful web sites to help tune Apache with PHP on web servers.
phpLens has a pretty detailed page on the subject that hits everything pretty well.
For the most part I agree with everything this page says. I do have a few other suggestions though.
Addressing the 3rd suggestion on the phpLens tuning Apache and PHP post, I recommend turning compression on for specific content types using the mod deflate module in Apache 2.0 or greater. Apache 1.3 uses a different compression module which is a bit more complicated to setup. Here is a link on ClarkConnect that describes how to add the deflate support to your web site and track its statistics with awstats. Don’t forget to compress javascript, css and xml as well as html.
Link: http://www.clarkconnect.com/wiki/index.php?title=Howtos_-_Activating_content_compression_on_Apache
Web server or module level PHP accelerators seem ideal for speeding up the performance of php scripts. Though the 6th suggestion, I would debate whether caching pages in the PHP level is faster or not. Libraries like Smarty are great for templating your pages but they have their limits. If you are hosting a web site with constantly changing dynamic content, the caching built into Smarty is minimal at best. Granted that your original PHP script was well written, the cached Smarty version technically can’t re-optimize your database queries, which is most likely the source of any delays with a dynamic web page.
One suggestion that is missing from the post is optimizing your SQL queries and methods how you select the data. phpLens mentions the concept of output buffering. What I am about to explain is similar and should be deployed together. First and for most, when you are working with a result set of data from a database, loop through all the data and store it in variables as quickly as you can and free up that queries resource. This will use the time you are connected to the database as efficiently as possible and prevent you from accidentally creating nested queries. Since this practice is very similar to output buffering, perhaps we should call it ‘database buffering’. The database may still buffer data as well, but your script knows better than the database what to do with the selected data and your script definitely knows what queries are going to happen next. Database buffering practices just make sense.
I would also recommend testing your web sites for security issues. Check out Nikto, it is a pretty powerful web server scanner that looks for vulnerabilities and security issues.
