Server Load and PHP
Moderator: General Moderators
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
- smpdawg
- Forum Contributor
- Posts: 292
- Joined: Thu Jan 27, 2005 3:10 pm
- Location: Houston, TX
- Contact:
How about using a package like ADODB so you can take advantage of their support cachine recordsets?
http://phplens.com/lens/adodb/docs-adod ... cheexecute
http://phplens.com/lens/adodb/docs-adod ... cheexecute
yeah, im actually working on a system that renders static html pages when needed, ie, updates made. I found this beneficial for two reasons, one, the rendering engine and the content server can run on two different systems, and two, serving plain html files is ultra fast.Buddha443556 wrote:I'm going to say this and run away and hide.
Content Caching = Post Design Optimization
Learn to do what content caching does for a script and you'll be better off.
1. Recognize static content.
2. Eliminate includes.
3. Store pages individually.
Bombs away!
On top of that, you can use output handlers like tidy to generate very nicely formatted and good xhtml AND it plays very well with search engines.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
I'm not advocating that rending static html as the best use for php. I am saying if a php script needs content caching because under load it slows to a crawl then someone should have put more thought into the design.bgzee wrote:yeah, im actually working on a system that renders static html pages when needed, ie, updates made. I found this beneficial for two reasons, one, the rendering engine and the content server can run on two different systems, and two, serving plain html files is ultra fast.
On top of that, you can use output handlers like tidy to generate very nicely formatted and good xhtml AND it plays very well with search engines.
What is content caching? It's storing a static snap shoot of your dynamic page in an individual file. The biggest bottleneck the content caching eliminates is that of hard drive weather that involves database queries or reading files. If one can learn to eliminate the bottlenecks then content caching may never be necessary. JMHO though.
I'd have to disagree. Even the most optimized code will use more cpu cycles then just being able to serve up some cached content.Buddha443556 wrote:I'm not advocating that rending static html as the best use for php. I am saying if a php script needs content caching because under load it slows to a crawl then someone should have put more thought into the design.bgzee wrote:yeah, im actually working on a system that renders static html pages when needed, ie, updates made. I found this beneficial for two reasons, one, the rendering engine and the content server can run on two different systems, and two, serving plain html files is ultra fast.
On top of that, you can use output handlers like tidy to generate very nicely formatted and good xhtml AND it plays very well with search engines.
What is content caching? It's storing a static snap shoot of your dynamic page in an individual file. The biggest bottleneck the content caching eliminates is that of hard drive weather that involves database queries or reading files. If one can learn to eliminate the bottlenecks then content caching may never be necessary. JMHO though.
Best way i can see to optimize code is to a, when possible (and when appropriate) have the SQL server do the work, such as string manipulation of fields, any arithmatic functions on fields, etc. Also, only using certain functions when approproate, for example array[] += vs array_merge. Then of course smart design implementation which will make sure you're not including tons of files everywhere. If you want to get real picky, use single quotes over double quotes.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
I'm not saying it would, I'm saying content caching is a bandaid approach to fixing a poorly designed script.bgzee wrote:I'd have to disagree. Even the most optimized code will use more cpu cycles then just being able to serve up some cached content.
I'm not pushing code optimization but design optimization. Unless your optimizing loops or such, code optimization is pretty unless with extensions like Zend Optimizer rewriting your code for you. MySQL can caches queries so even SQL optimization will have limited returns. However, eliminate a dozen include files for a page and your going to see a performance increase.Best way i can see to optimize code is to a, when possible (and when appropriate) have the SQL server do the work, such as string manipulation of fields, any arithmatic functions on fields, etc. Also, only using certain functions when approproate, for example array[] += vs array_merge. Then of course smart design implementation which will make sure you're not including tons of files everywhere. If you want to get real picky, use single quotes over double quotes.
I think we somewhat agree here, but I think I've been down this road before:
viewtopic.php?t=19906&start=30&postdays ... highlight=
I thought zend optimizer cached compiled scripts so it didnt have to be reinterpreted every time it was accessed? Regardless, even if zend optimizer does optimize the code, there is only so much it can do. For example, if your using two loops for what could be done in one loop, im sure that the zend optimizer will not know that.Buddha443556 wrote:I'm not saying it would, I'm saying content caching is a bandaid approach to fixing a poorly designed script.bgzee wrote:I'd have to disagree. Even the most optimized code will use more cpu cycles then just being able to serve up some cached content.
I'm not pushing code optimization but design optimization. Unless your optimizing loops or such, code optimization is pretty unless with extensions like Zend Optimizer rewriting your code for you. MySQL can caches queries so even SQL optimization will have limited returns. However, eliminate a dozen include files for a page and your going to see a performance increase.Best way i can see to optimize code is to a, when possible (and when appropriate) have the SQL server do the work, such as string manipulation of fields, any arithmatic functions on fields, etc. Also, only using certain functions when approproate, for example array[] += vs array_merge. Then of course smart design implementation which will make sure you're not including tons of files everywhere. If you want to get real picky, use single quotes over double quotes.
I think we somewhat agree here, but I think I've been down this road before:
viewtopic.php?t=19906&start=30&postdays ... highlight=
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Nope, it optimizes intermediate code doesn't cache anything.I thought zend optimizer cached compiled scripts so it didnt have to be reinterpreted every time it was accessed?
True, no argument.Regardless, even if zend optimizer does optimize the code, there is only so much it can do. For example, if your using two loops for what could be done in one loop, im sure that the zend optimizer will not know that.
Using the best algorithm always helps which could be considered a design issue.Unless your optimizing loops or such, code optimization is pretty unless with extensions like Zend Optimizer rewriting your code for you.
Have you tested that? Try benchmarking with apache ab. I doubt you could tell the difference. I'd also recommend messing about with Xdebug. Both of these will help to provide a perspective on what is and is not significant.Buddha443556 wrote:However, eliminate a dozen include files for a page and your going to see a performance increase.
Unless you're doing anything really daft, script optimisation is a waste of time. Concentrate on creating a good OOP design. When you're done, that's the time to think about optimising, if you need to. It's unlikely that you'll be able to find any significant gains and db access will swamp the odd micro-second you might pick up here and there in the php anyway.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Hmm ... we actually agree here:

... and even here if script optimization = code optimization:McGruff wrote:Concentrate on creating a good OOP design.
But lets just continue to disagree about everything else? After all we never agreed before on this subject, let's not change a good thing eh?McGruff wrote:script optimisation is a waste of time.