Page 2 of 2
Posted: Wed Feb 23, 2005 6:44 pm
by Buddha443556
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!
Posted: Thu Feb 24, 2005 1:19 am
by smpdawg
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
Posted: Thu Feb 24, 2005 10:32 am
by bg
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!
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.
Posted: Thu Feb 24, 2005 12:16 pm
by patrikG
content caching and static pages are one way of performance optimising, code-optimisation under PHP is a different story, same goes for DB-optimisation.
Posted: Thu Feb 24, 2005 12:32 pm
by Buddha443556
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.
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.
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.
Posted: Thu Feb 24, 2005 12:36 pm
by patrikG
performance optimising could also mean using pre-compilers such as ZendOptimiser, eAccelerator, APC. But does it actually optimise your PHP-code? Nope.
Posted: Thu Feb 24, 2005 2:20 pm
by bg
Buddha443556 wrote: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.
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.
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.
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.
Posted: Thu Feb 24, 2005 3:24 pm
by Buddha443556
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 saying it would, I'm saying content caching is a bandaid approach to fixing a poorly designed script.
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'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.
I think we somewhat agree here, but I think I've been down this road before:
viewtopic.php?t=19906&start=30&postdays ... highlight=
Posted: Thu Feb 24, 2005 3:44 pm
by bg
Buddha443556 wrote: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 saying it would, I'm saying content caching is a bandaid approach to fixing a poorly designed script.
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'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.
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.
Posted: Thu Feb 24, 2005 3:57 pm
by Buddha443556
I thought zend optimizer cached compiled scripts so it didnt have to be reinterpreted every time it was accessed?
Nope, it optimizes intermediate code doesn't cache anything.
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.
True, no argument.
Unless your optimizing loops or such, code optimization is pretty unless with extensions like Zend Optimizer rewriting your code for you.
Using the best algorithm always helps which could be considered a design issue.

Posted: Fri Feb 25, 2005 9:34 am
by McGruff
Buddha443556 wrote:However, eliminate a dozen include files for a page and your going to see a performance increase.
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.
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.
Posted: Fri Feb 25, 2005 1:51 pm
by Buddha443556
Hmm ... we actually agree here:
McGruff wrote:Concentrate on creating a good OOP design.
... and even here if script optimization = code optimization:
McGruff wrote:script optimisation is a waste of time.
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?
