> -----Original Message----- > From: Bastien [mailto:phpster@xxxxxxxxx] > Sent: Sunday, December 12, 2010 9:20 AM > To: Nathan Rixham > Cc: Lester Caine; php-general List > Subject: Re: ORM doctrine > > > > 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. You're just proving the points I made. The app was poorly designed because he/she didn't truly understand my point #2: understand the objective + possible growth/expansion. Also, mostly like that he/she didn't fully understand point #1: understand the problem (needs of the business, programming language in use, etc). Failing both points 1 & 2 will make point 3 even far worse. Hence you had to 're-architect'. Regards, Tommy > > 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
