Lester Caine wrote:
Nathan Rixham wrote:
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

Actually THAT probably sums things up nicely. An approach suitable for MySQL WILL probably be wrong for Postgres or Firebird. Certainly the optimised SQL I use for my own applications is much improved if I simply ignore compatibility with the databases other developers are using. Libraries like doctrine and even PDO are probably not using the best approach that a database specific approch may take. Firebird will maintain the 'results' of previous searches in cache and give results sets a lot faster, such as being ready to return the next page of results BEFORE the web page asks for it ;) But a database agnostic approach is not as efficient.

Yes, but you snipped a key paragraph there, because all the forms of caching and optimization listed above, including db cache optimization will only increase performance of the app by small percentages, whereas moving to a publishing model and producing static output will increase performance by several factors:

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.

Feel free to ignore this yourself, but please don't promote a bit of SQL and db server optimization as being the most important factor in optimizing PHP applications, it is important, but the net result is minimal in comparison to leveraging HTTP caching and static publishing of components or entire documents.



PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to