Hi Jochem.
the nice thing about programming with my 'data framework' is that its
very generic, flexible and interspective (generating abitrarily complex
sql/html/? from objects) ... which comes with a great cost.
so I have code that is really very very heavy but if you consider
the (complete|discount|standard|bundeled) price calculation routines
for the site I was speaking of, are 1000's of lines in themselves you
might agree that a more structured apporach to the code bear fruits
in maintainability/extensability (which has been my finding overall).
bottom line is [they] have to buy a bigger box. :-)
actually my real problem lies in not being [cap]able of using the
Smarty cache (I can't figure out how it works/how to use it)
I'm thinking that output (HTML) caching might be an option for you - you
seem to be hinting at that with the Smarty reference above. Probably
depends mostly on how many variables you have to deal with. And I would
still look into using MySQL level caching as well if the query execution
time is more than a second or two.
I'm in the process of optimising a CMS at the moment which fits your
description of "very generic, flexible and interspective (generating
abitrarily complex sql/html/? from objects) ... which comes with a great
cost." The biggest bottleneck in my app was not complex SQL, but PHP
picking up all the include files (classes etc.), but that's beside the
point.
In my project I implemented an output cache (caching just the HTML)
based on the full URI for text/html content-type GET requests - taking
into consideration the query string parameters. Admittedly it's a very
aggressive cache, and I may have to change it to allow for flexibility
based on user ID or other parameters, but it does improve performance
significantly. I query the cache before loading my framework, which is
where most of the performance benefit comes from in my particular app.
Another benefit to this approach is that it would be fairly easy to code
the caching system "around" your existing framework i.e. if no cache
hit, handle the request using your framework, then store to the cache
via the output buffer.
As far as I know you would be able to use APC for this type caching (I
haven't used APC but have read up on it a little recently). It might
even be possible to GZIP the output before caching to reduce memory
requirements, at a small performance cost when dynamically generating
the content. The approach could also be used for HTML fragments (i.e.
just the changing area - the results listing HTML etc.)
FWIW, Smarty probably doesn't do quite what you want (I use Smarty in
the CMS, but afaict you need to know the template name + a unique ID to
use the cache - if the template name can be hard coded, no dramas, but
if it's dynamically loaded, it becomes trickier - including the Smarty
class also incurs a performance overhead).
Not sure if any of that's useful?
BTW, if anyone sees any serious issues with this approach, let me know.
I don't intend to roll out the solution to a live system for a while, so
I still have plenty of time to revisit.
Regards, Grant
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
