Just a quick checklist if you aren’t getting anything written to the PHP error log on your server:
php.ini, do you have
error_reporting set to
php.ini, do you have
log_errors set to
php.ini, do you have
track_errors set to
- Have you specified a valid file / location for
- Does the user that starts PHP (Apache) have relevant permissions and ownership to write to that error_log file ?
- Does your application have an override set in
php.ini for any of the above?
- Have you restarted PHP/Apache after making changes for these things to take effect?
- What does
php -i | grep error tell you regarding these settings?
If you run PHP through Apache (as a module rather than standalone), then it can be quite hard to track down which scripts are actually running at any given time on your server. This is particularly true on production environments where you can’t attach tracing (e.g. strace) to Apache.
However, there is a way to tell using the command
If you run the following in the root directory of your web application:
sudo lsof +D /var/www/yourwebapp | grep php
It will give you a list of all the PHP scripts that are currently open right now. Very handy to “see” inside what apache is doing and track down possible culprits for things like performance issues.
Note you need to have sudo access to do this as you need to be able to access the files open by the user that started apache.
I’ve spent a lot of time this year investigating and resolving performance issues due to high load on a PHP web application (Moodle). The load we are talking about here is up to around 2000+ visitors per hour (accordingly to Google Analytics).
The following is a list of general advice on performance tuning. Note it isn’t all technical. How you go about the process is just as important as the technical changes.
- Implement some form of analytics to track load. Google analytics with the real time monitor is fantastic. Don’t switch this off, even during high load, otherwise you will be flying blind and it will hurt your efforts more than help (if you can’t measure it, you can’t improve it).
- Invest time on proper load testing scripts that simulate high load behaviour so you can measure and improve. Jmeter is great for this, but there are many tools out there to help you.
- The database (MySQL in this case) has a huge impact on performance. Two very important things to look at are thread cache size (make sure it is on) and if using InnoDB, your InnoDB buffer pool size. Be sure to check out the excellent MySQLTuner perl script to help you get this right. Monitor your database and logs to find what might be holding things up. Apache relies on MySQL being snappy, if it is slow you’ll have bottlenecks further up the chain.
- For all layers, its important to realise that the defaults won’t do. Tuning/tweaking is required to get the most out of your web server and database server. There’s a wealth of information out there, do your research and monitor your system to find the bottlenecks.
- Document your changes. If you don’t know what you changed, then how can you tell what helped (or didn’t)? Be systematic. This isn’t the time to go around randomly changing things and hoping for the best.
- Don’t make assumptions. It might sound strange but this is a huge one. A lot of performance tuning efforts are hindered by people assuming where problems are rather than finding them through proper metrics (e.g. load testing and monitoring). If you can’t measure it, you can’t call it (regardless of your “experience” and so on).
By default on Apache web servers, PHP code will not execute in a file that does not have a .php (or similar) extension. So even though you can embed PHP into a HTML file, it won’t execute when the file extension is .html, .htm etc.
To change this, you can add a .htaccess file. Here’s some example code to add depending on your system:
AddType application/x-httpd-php .html .htm
For certain hosting providers you may need to do this:
Addhandler application/x-httpd-php5 .html .php
Put this in a file called .htaccess in the same folder as your HTML files.
Turns out that you can apply virtual host changes in Apache config (httpd.conf) with a graceful apache restart, rather than a full restart which forcibly kicks (which means kicking users off your web server).
Here’s how to do a graceful change:
- Change the httpd.conf file accordingly
- Check your config with sudo service httpd configtest (make sure you get syntax OK)
- Issue sudo service httpd graceful (most Linux variants)
Note quite a few other Apache changes take effect with a graceful restart. Well worth trying this first, before resorting to a full restart.