On 2010-12-12, at 11:45 AM, Nathan Rixham <nrixham@xxxxxxxxx> wrote: > 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 >>> optimizations. >> 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. > > Best, > > Nathan > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > I would definitely agree with Nathan here. In our classic asp (don't ask) the vp of our company designed a survey app ( poorly I might add ) that dynamically generated the form and all of it's associated drop downs including the locations ( some 2000 of them ). The client was requiring 1000 user concurrency and the app as it was only handled 10 users. I re-architected the app to cache out the form since it was identical for each user, and we easily hit the required benchmark. Form caching is one of the most important omptimizations that can be made ( especially in our app where a major ( and I am not allowed to fix it ) design flaw loops through the form and associated data set 4 ( yes, 4! ) times and nothing is cached ). Db calls are expensive but not as expensive as extremely poor design! Bastien Koert Sent from my iPhone -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
