RE: ORM doctrine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----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



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux