Print
Quick performance tips for PHP and Apache
By Dave Redfern (Writer)
Published: 18 Nov 16:31 in Web Development
This is a set of tips to gain some extra performance out of PHP and Apache without requiring huge amounts of effort.
Lately I have read a number of posts looking at performance of frameworks, tuning and benchmarking. So I decided to try this out with my own Scorpio framework to see how it faired. This has lead me to some interesting findings that I was not previously aware of. These are a few (probably already known tips) that I am including more for my own reference but hopefully they might be useful to someone else out there too. These are in no particular order.
-
Put your web files in the web-server root folder
Now this might seem amazingly obvious, but simply moving your files and folders into the servers webroot e.g. /var/www/ or C:\wamp\www\ will give you a performance boost. Less folders to parse for config files etc. This may impact Windows machines more than Linux; I have not confirmed it yet. But doing a simple ab test on my dev box netted around 15-20 requests/second increase from that alone (your mileage will vary).
-
Remove all PHP error notices and warnings
Again, this has been posted about by other people and was a feature of Rasmus Lerdorfs presentation "Simple is Hard". If you have warnings or errors, PHP will load all that information for each one - even if suppressed using @. It just goes to /dev/null or whatever. So fix it! That includes un-initialised variables as well.
-
Remove logging or reduce it as much as possible in production
I love logs. I like to log out "stuff" that is happening, events, actions audit trails etc. Scorpio has a great logging system... unfortunately that is actually quite a serious amount of work as far as running a framework is concerned. So either short-circuit your logging or remove calls to the logging system (which might not be possible). Sometimes just dropping your log-level is not enough. However if you go overboard, then debugging issues will be extremely hard - so it is a fine line.
-
Keep .htaccess files to a minimum and if possible move it all into the apache config
Being able to override .htaccess files is great; what is not so good is if you have a heavily nested web-facing directory structure. Each folder has to be checked for .htaccess files and applied in turn. If you can; shove them all in the apache config.
-
Avoid setting PHP values in .htaccess files
For a start, it does not make much (if any) sense, but it makes it much harder to maintain production / development values. Especially if you accidentally move a .htaccess file into version control and it gets on to production (or vice-versa!). You may find you have weird issues that are hard to debug. Using a different name for .htaccess files is not a solution, it just makes it more confusing. From a peformance point of view, it is more work for Apache and PHP as the various .htaccess files PHP values have to be merged into the main config.
Instead just change the php.ini, or if you do not have access, use a custom php.ini. If you cannot use a custom php.ini, use ini_set in your application. If you cannot do that, then consider a different host or look again at what it is you are trying to do.
-
Avoid initialising a database connection
Again another fairly obvious point, but if you do not need to use the database - don't create a connection to it. It takes time and if you never use it, is a waste of a connection. However, you can initialise a connection string - but not the physical connection i.e. prepare the DSN ahead of time.
-
Avoid recursing file system paths
Yet another starggeringly obvious point, but one I was not truly aware of until I saw the results in black and white. Scorpio uses a hierarchial website structure. In this a site can "extend" another site and replace functionality on an ad-hoc basis. All this flexibility comes at the costs of having to resolve the file path for EVERY request. This can be repeated calls across the file system to find the actual path to the view or controller. Caching helps, but if it is not needed - create a custom router that short-circuits the functionality - something that will be added to Scorpio in due course. This is actually more specific to the way that Scorpio works than any other framework.
-
Autoloading is your friend
There have been some posts that autoloading (__autoload(), spl_autoload_register()) are bad because they do not work with APC or other cache utilities. This is not what I have observed. APC etc may not be as efficient - but they still work.
First point; there is no negative impact in using autoload. You can check that by loading in APC and the using the APC.php file to check the activity, you will see it logging cache hits and misses etc.
Second point: using autoload ensures that you are only loading the resources you actually need to use to process the request. You can create class maps that point classes to files to keep this tidy and avoid un-necessary disk accesses a'la ezComponents and Scorpio (which is based on the ezComponents model).
-
require_once() can be painful
Using require_once() can be very slow. You should use it only where a file absolutely has to be required and only once. Better is to use include_once() or if you think you can get away with it just a straight include() though for library code, include_once() is preferred as you may accidentally include the same library from multiple files and that will cause parse errors from previously defined functions.
-
Avoid or minimise complex configuration files
Config files have to be parsed, the bigger and more complex they are, the longer this takes. Most frameworks (Scorpio included) do not cache parsed config files. So for every request, all the config files have to be loaded, parsed, assembled etc. This again is probably more an issue with Scorpio as each sites config file can override the parent so each has to be parsed in turn; though this only happens where values are missing. Caching of the site config files is something that will be introduced in the next version of Scorpio.
I am sure that many people will disagree or think that this is too obvious, but sometimes it is good to be reminded of the simpler things that can often be overlooked.
The last point is from another post; avoid pre-emptive optimisation. You never know what will happen to your application and sometimes only in the final stages can you properly analyse and make informed choices on where to spend the time for performance tweaks.