Re: ORM doctrine

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@gmail.com> 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