Re: ORM doctrine

Nathan Rixham 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.

For fixed pages this is the best way of handling the information. And handling those fixed pages is ... from my point of view ... not a problem since they can be cached at that level, or even stored locally in the browser cache. I've just been hitting re-load every time for a few updates I've just been processing! In order to actually see the result. But for the majority of my work, the data to be displayed is being rebuilt with every browser hit. In that case generating dynamic pages fast becomes the bottleneck. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php