Hi All,
Apologies for wading in to this discussion, however I must point out
that caching at every level is very very important.
As Peter says, caching is not an optimization to be thought of later, it
is not the icing on the cake, rather, caching is one of the most
critical design factors, to be considered on every component, layer and
tier in an application, at every edge.
Our end goal as developers, is not to create big ol fancy systems, it's
to create systems which answer questions as quickly as possible, every
time a request comes in to one of our applications, our job is to have
created code which can respond as quickly as possible.
The ultimate level of optimization in any system, is to have the answer
ready before the question has been asked, to have the response ready
before the request has been made.
Every time any part of your application runs more than once and produces
the same result, you've failed a little bit. Every time your entire
application runs and produces the same response as the last time it ran,
you've failed a lot. These failures soon mount up to a fail of epic
proportions.
We're talking about applications which are not just 10% more performant
across the network, but several thousand times more. The difference
between a server handling 10 concurrent requests per second and 10000
concurrent requests per second.
Caching is not a minor optimization to be thought of later, it's not
something to take lightly, it's pretty much the most important design
principal there is, period.
As a web developer, the most important interface you need to introduce
caching on, is HTTP - a "static" or "published" HTML document which
leverages HTTP caching using Last-Modified / ETag headers will give
circa 100 times better performance (or more) than a dynamically
generated each time doc. Not only that, but transparent proxies on the
network can come in to effect and reduce weight on the server to zero,
and further, web browsers will serve repeat requests to the document
straight from RAM, again leading to zero weight. When you include those
two factors it doesn't take long to see that the performance difference
over the network is so good that it's nigh on unmeasurable.
In your application itself, caching can be introduced at every level,
you've already got filesystem io caches provided by the operating
system, a well tuned db server cache can make a big difference as well,
then on to opcode caches in languages like PHP since it's interpreted
rather than compiled, and then on to code optimizations such as using
static class cache's behind getByID methods and similar, and finally
down to micro optimizations, static code analysis and dead code
elimination, replacing (4*10) with (40), inlining static class members /
constants and such like. Finally, language specific nuances and micro
optimizations.
Again, I stress, caching is not an optimization, an application which is
designed to not repeat itself (via caching), is a good, scalable, ultra
performant application, and that's what we, as developers, are paid to
create.
Best, and thanks for taking the effort to point this out to the list
thus far Peter,
Nathan
Peter Lind wrote:
On Sunday, 12 December 2010, Tommy Pham <tommyhp2@xxxxxxxxx> wrote:
Peter Lind wrote:
Your posts seem to indicate that caches are only useful when other
parts of the app have been done wrong. My point was that this is a
fairly fundamental misunderstanding of caches - regardless of what you
are or aren't capable of optimizing.
CHACHES are only useful when there are static views of the information
available. Only static elements can be cached with any real chance of
performance improvement, so part of what Tommy is saying is correct.
Although the way he has worded that is perhaps a little misleading?
Possibly. However, thinking that a cache is something you apply at the
end of development means you may well bar yourself from better uses of
one. Ie. thinking that a cache is "icing on the cake" prohibits you
from "mixing it into the cake" (to further abuse a metaphor) which
could give you "a better recipe".
I may have misunderstood the topic, but a cache to me is more than
just storing views. It's also the db cache, memcache, apc, etc. You
have to think about how you use these - some of them can't just be
slapped on to your app after development.
Data caching SHOULD always be the
domain of the database, so duplicating that in PHP is pintless.
So you're saying one should never use memcache for storing data from the db?
Regards
Peter
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
