Nathan Rixham wrote:
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.
If you've got an example, and you'd like to know how to approach these
problems, I'd be happy to go through the process of making these always
dynamic pages HTTP friendly with you :) (and on the list or in private)
I'm quite happy with my current page generating process, but we are always
looking for ways of improving the base bitweaver framework. When the original
port was done from tikiwiki, we changed from a large percentage of processing
time accessing the database to establish even if a user was allowed to access a
page to something a lot more responsive and a lot less sensitive to DOS attack.
Certainly improving the 'static' base on which the dynamic information is laid
is an area where page generation times could be reduced.
doctrine is an abstraction layer that I had a play with some time back, but in
many cases we are building a multi-table query that returns all of the data in a
single result set ... including the selected security model ... and that is
something that ORM does not seem to provide an easy access to? But I stand to be
corrected on that.
--
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
