I’ve just noticed that my app is including over 148 php files on one page. Bear in mind this is the back end admin and not the main site, but is this too many? What impact does a large number of includes have on a server, both whilst under average load and stressed? Would disk I/o be a problem?
Included File Stats
File Type – Include Count – Combined File Size
- Index – 1 – 0.00169 MB
- Bootstrap – 1 – 0.01757 MB
- Helper – 98 – 0.58557 MB – (11 are Profiler related classes)
- Configuration – 8 – 0.00672 MB
- Data Store – 23 – 0.10836 MB
- Action – 8 – 0.02652 MB
- Page – 1 – 0.00094 MB
- I18n Resource – 7 – 0.00870 MB
- Vendor Library – 1 – 0.02754 MB
- Total Files – 148 – 0.78362 MB
Time ran 0.123920917511
Memory used 2.891 MB
Edit 1. Should be noted that this is a worst case scenario page. It has many different template models, controllers and associated views because it handles publishing with custom fields.
Edit 2. Also the frontend has agressive page caching so the number of includes in the front is roughly 30-40 at the moment.
Edit 3. Profiler when turned off won’t include the files so this will reduce quite a few includes
So, here’s a breakdown of the potential problems.
The number of files itself is an issue. Unless you’re using a bytecode cache (and you are), and that cache is configured to not stat the file prior to pulling in the compiled bytecode, PHP is going to stat every single one of those files on include, then read them in. In some cases, that can also mean path resolution and a naive autoloader that pokes and prods at numerous directories. This won’t be “slow” because the OS will surely have things cached if the files are hit frequently, but it does add precious milliseconds to each request.
If every autoloader is designed properly and the codebase relies entirely on the autoloader to pull in the required classes (meaning nothing uses include/require/include_once/require_once on a class file), you can avoid having to open and read many of the files by gluing every single class together into a single large include. This is a bit on the impractical side of things, mainly because if there is no bytecode cache, PHP still has to parse, compile and interpret it all. Additionally, not every class is going to be used on every request, so it may be a bit wasteful.
The bottom line is that a well-configured bytecode cache will completely mitigate this problem. There’s nothing wrong with telling your customers that they have to properly configure their servers for optimal performance. If they know what they’re doing, they’ll have everything correct to begin with.