> -----Original Message-----
> From: Bastien [mailto:phps...@gmail.com]
> Sent: Sunday, December 12, 2010 9:20 AM
> To: Nathan Rixham
> Cc: Lester Caine; php-general List
> Subject: Re: [PHP] ORM doctrine
> On 2010-12-12, at 11:45 AM, Nathan Rixham <nrix...@gmail.com> 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
> 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
> 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
> 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
> 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
> db server optimization as being the most important factor in optimizing
> applications, it is important, but the net result is minimal in comparison
> 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)
> 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
> 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'.


> 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 )
> flaw loops through the form and associated data set 4 ( yes, 4! ) times
> 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

Reply via email to