How many includes per request?
Moderator: General Moderators
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
How many includes per request?
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?
One poster, at Sitepoint, referred to Rasmus Lerdorf suggestion of 5 or less includes as a foolish dream. Anyone here achieve this?
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.
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.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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...
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...
You just couldn't specify another application component, right?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.
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.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
I ran into it, but not quite what you mean, so I'll explain.Maugrim_The_Reaper wrote:I have yet to see a major, worrying side effect on performance. And IMHO its nearly unavoidable.
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.
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.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...
There are definitely times where a pile of includes is the more "right" choice, and times where fewer is better. Its all relative.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.
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.
-
d3ad1ysp0rk
- Forum Donator
- Posts: 1661
- Joined: Mon Oct 20, 2003 8:31 pm
- Location: Maine, USA
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.
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.
- AKA Panama Jack
- Forum Regular
- Posts: 878
- Joined: Mon Nov 14, 2005 4:21 pm
Re: How many includes per request?
Well, it all depends upon what the includes happen to be and how they were written.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?
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.
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.
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?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
- AKA Panama Jack
- Forum Regular
- Posts: 878
- Joined: Mon Nov 14, 2005 4:21 pm
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.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?
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.
Last edited by AKA Panama Jack on Thu Dec 29, 2005 3:22 pm, edited 1 time in total.