Page 1 of 2
How many includes per request?
Posted: Thu Dec 22, 2005 9:53 am
by Buddha443556
A recent topic at SitePoint got me wondering how many includes are acceptable per request? I don't think there's a single right number. I figure this number varies according to the hardware, PHP setup, traffic and even business environment.
One poster, at Sitepoint, referred to Rasmus Lerdorf suggestion of 5 or less includes as a foolish dream. Anyone here achieve this?
Posted: Thu Dec 22, 2005 10:25 am
by josh
There really is no golden rule, it depends entirely on the application, hardware and performance needs. On a site that is just pulling content from a database I usually keep the includes under 3. On a complex application that is using a huge library of files it could be 20 includes.
Posted: Thu Dec 22, 2005 10:32 am
by hawleyjr
For every application I have:
1. Global Includes files. Non application specific constants.
2. Application Specific constants
3. DB connection class
4. DB QueryHandler Class
5. Application functions
6. User Verification include (If user validation is needed)
7. Footer (Copyright info)
And of course, links to any application specific classes I'm using.
It's not uncommon for me to have over 20 includes in a complex page.
Posted: Thu Dec 22, 2005 12:02 pm
by John Cartwright
On my current app, I have 13 automatic includes, and about another 10 or so depending on the page request. I have yet to see any concerning performance issues, although I have yet to test under high loads.
Posted: Fri Dec 23, 2005 4:02 am
by Maugrim_The_Reaper
Its quite simple - if you use OOP, split classes into separate files for re-use later, use a library based approach (another incentive for re-use), and use a certain well debated design pattern...
Easily 20, that seems the average mark. For something more complex, and with a security bundle directly re-usable - more like 30. I can also hit 40 if necessary.
I have yet to see a major, worrying side effect on performance. And IMHO its nearly unavoidable. You could of course turn procedural - you'd get your upper limit of 3 included very quickly in that direction - with the cost of including massive transaction scripts with a few thousand lines of redundant code for the applicable request...
But if you look upon re-use, maintenance, 1 class-1 file, max 3 levels of inheritance, and other factors it just becomes inevitable for an OOP application.
As for performance hits - a lot is going to depend on the server - HDD access time and all that malarky. I've seen worse performance with 5 includes that are basically badly designed procedural. If you the overall view - 30 includes for a good design will often beat 3 includes in a bad design consistently. Focusing on one performance measure - disk access X number of includes is misleading...
Posted: Fri Dec 23, 2005 4:42 am
by onion2k
The rule is pretty obvious: A few as possible without compromising the maintainability of your code.
Posted: Fri Dec 23, 2005 8:20 am
by pilau
hawleyjr wrote:For every application I have:
1. Global Includes files. Non application specific constants.
2. Application Specific constants
3. DB connection class
4. DB QueryHandler Class
5. Application functions
6. User Verification include (If user validation is needed)
7. Footer (Copyright info)
And of course, links to any application specific classes I'm using.
It's not uncommon for me to have over 20 includes in a complex page.
You just couldn't specify another application component, right?

I have the same list exactly when it comes to includes. I never have passed 13 includes though
I believe that if you need an include, include it! The structure and maintenance of your code should be of high priority.
Posted: Fri Dec 23, 2005 10:16 am
by Buddha443556
I wonder how big an influence the structure of the script has on the number of includes? Front controller vs Page Controller. When I use a Front Controller I also use a lot more includes than with a Page Controller. Which makes sense in a way because a Page Controller has less responsibility.
Posted: Fri Dec 23, 2005 12:43 pm
by Roja
Maugrim_The_Reaper wrote:I have yet to see a major, worrying side effect on performance. And IMHO its nearly unavoidable.
I ran into it, but not quite what you mean, so I'll explain.
In the game I work on, we ran into a situation where we had been essentially putting everything into every page for simplicities sake.
So, in a given page, we'd have (for example) a header, a footer, the variable setups, the database class, the template class, and more.
The result was that many pages were loading classes and libraries that they didn't actually use.
That meant that a non-trivial number of pages were non-trivially impacted. How much? My measurements showed a roughly 15% increase in pages served per second by optimizing the includes throughout the game.
Now, that may seem a trivial amount, but the game has over 150 unique "pages". Gaining a 15% improvement across that large of a codebase is definitely worthwhile. Granted, the (vast) majority of servers running BNT haven't reported performance issues, but we want to keep it that way by continuing to aggressively optimize as we develop.
We do not however optimize purely for the sake of optimizing. We had the opportunity to replace adodb with adodb-lite, which would have resulted in an improvement. However, that improvement in processing time and memory use
also meant a reduction in functionality that we used. Worse, one of the main functions we would lose (performance monitor) would have deeply reduced our ability to continue optimizing the game. (To be fair, adodb-lite does offer general performance monitoring, but we need specific monitoring)
Its a tricky balance, and every site/game/webapp has its own "right" choice, with varying degrees of effectiveness.
Maugrim_The_Reaper wrote:As for performance hits - a lot is going to depend on the server - HDD access time and all that malarky. I've seen worse performance with 5 includes that are basically badly designed procedural. If you the overall view - 30 includes for a good design will often beat 3 includes in a bad design consistently. Focusing on one performance measure - disk access X number of includes is misleading...
Very true. Credit where it is due, from the benchmarks PanamaJack has shared, it appears that adodb-lite has saved substantial overhead for AATraders. Since I'm not willing to make that tradeoff, I have to hunt for similar gains elsehwere. I think the overall choices have worked out well.
There are definitely times where a pile of includes is the more "right" choice, and times where fewer is better. Its all relative.
Posted: Fri Dec 23, 2005 2:14 pm
by Ambush Commander
I follow the Java style of giving every class its own page, so that racks up to a lot of pages.
The Writing Pot (complex and legacy) =~ 46
CoLocus (fairly simple) =~ 17 + 1
Taiji Club (very simple) =~ 0 (it's all procedural)
However, I must remind you: many of these costs can be mitigated almost completely with a compiler cache. However, I see places where I could have been more selective in what I chose to include.
Posted: Fri Dec 23, 2005 11:50 pm
by d3ad1ysp0rk
Hmm, not sure where I took a wrong turn, but my actual job is PHP development and I do it as a hobby, but I've never gotten more than 6 includes on something I've written. This includes full fledged web sites/CMS and blah blah blah.
What could you possibly need 40 different classes (or includes alone if it's procedural) for? A client who said "I need this 4 gig database with 65 tables to be displayed using graphs, percentages, and one auto-csv dump, all on one page"?
I just can't think of any single page that would require that much code.
Re: How many includes per request?
Posted: Tue Dec 27, 2005 10:14 pm
by AKA Panama Jack
Buddha443556 wrote:A recent topic at SitePoint got me wondering how many includes are acceptable per request? I don't think there's a single right number. I figure this number varies according to the hardware, PHP setup, traffic and even business environment.
One poster, at Sitepoint, referred to Rasmus Lerdorf suggestion of 5 or less includes as a foolish dream. Anyone here achieve this?
Well, it all depends upon what the includes happen to be and how they were written.
Include files that are classes take more time, memory and cause a greater CPU load than an include that is just a function or inline execution of code. The main reason for this is how PHP has to dynamically allocate memory for the included file and the instance for the class when it is created. With an include that is just a function or inline code memory is only allocated for it once.
The larger and more complex the class the more load you will be placing on the server and the more memory that will be allocated. If you had a page that loaded 10 large classes and another page that did the same thing but loaded 10 large functions/inline code you would find the class page would be much slower, more memory inclusive and far more CPU load intensive. Your maximum pages per second vs CPU loading would be horrible using the large classes.
So it all depends upon what your includes are doing and how you are using them.
In our Alien Assault Traders game we have one page that loads 10 include files of varying size that are all functions and not classes and we load two classes. There is absolutely no difference in CPU loading or execution time if we use 10 include files or have them all combined into a single include file on my work server. If you are using something like eAccelerator that can precompile and cache every PHP file you will notice no difference either with the caching options enabled between the loading of ten include files vs one.
BTW, most servers, especially hosting services will use file caching either through software or through various hardware means (drives, controllers, ect).
There is a point where the number of files you include can become a problem for server performance but you would have to really be trying.

The worst offenders would be loading of classes.
Roja talked about his game and a good example would be the last release he made of TKI that used a shotgun effect of loading all kinds of classes, many that were not used in normal operation of the game. Let's just say that compared to an earlier version of TKI that didn't shotgun in a bunch of classes the server load increased 3-4 times and pages per second that could be displayed dropped to between 20 and 25% of the number of earlier versions of the game.
So you have to be very, very careful about what you include. As I said before classes can be your downfall if you don't manage what you are inlcuding.
Posted: Thu Dec 29, 2005 11:03 am
by Moocat
I think I get what you're saying throughout most of that post, but when you said you have to manage your classes correctly exactly what do you mean? Should I make my classes larger and fit in as few files as possible? Or should I try to make everything into functions when possible instead of putting the functions inside the classes? or something completely different?
Posted: Thu Dec 29, 2005 2:37 pm
by Ambush Commander
Strive to make your code as readable as possible. Then optimize.
Posted: Thu Dec 29, 2005 3:06 pm
by AKA Panama Jack
Moocat wrote:I think I get what you're saying throughout most of that post, but when you said you have to manage your classes correctly exactly what do you mean? Should I make my classes larger and fit in as few files as possible? Or should I try to make everything into functions when possible instead of putting the functions inside the classes? or something completely different?
Well, the biggest problem is how people will include a class that is huge but only has maybe one function that they need. It's not the number of includes but the type and size of the includes that is the problem.
An example would be including a 200k class where you only want to use one feature of the class and that feature would normally be maybe 10k. The 200k class causes a considerably larger load on the server when it is included and the object created compared to a 10k class. This larger load is increased CPU load and a slowdown in generating each page. Sure it is nice to find a class package that does what you want but if it includes a bunch of extraneous code you will not use then it is a detriment and an alternative should be found. If you can do the same thing using a 10k included function instead of a 10k included class that is even better as it is much faster and doesn't require the need to allocate memory and compile for a new object which reduces CPU loading as well as increases the pages per second that can be generated.
One of the worst problems are class packages that use extensions to replace existing functions in a class. This vastly increases the overhead and greatly slows down creating an object. Properly written classes will use extensions to ADD new functions to a class and not overwrite existing class functions if they want to have low memory usage, high speed and low server loading with PHP.
With PHP it is not the number of includes but the type. Large classes in PHP are slow to create objects from, use more memory than you can imagine and greatly increase CPU loading when an object is created from the large class.
Classes are a nice feature but some people tend to overuse them to the detriment of the server when they really are not needed for most web applications. You will find that, in most cases, a web application written entirely as a set of classes will be slower and more resource intensive than a similar web application that is classless. And don't buy into the myth that Class programming is more structured.
Classes in PHP still have a long way to go before they can be considered efficient for basing entire web applications.