Sameer, Funny, recently I've been thinking about having a "global" ETag key, too. The only problem I see is: how do we determine whether the ETag key sent by the browser should generate a cache miss or hit? Gregarius loads all his content from the database, so we should at least check whether new content has been added since the provided ETag was issued. I think we should put some effort into separating the database subsystem from the rest, then: - load the db system - check the date of the last update for the requested page/feed/item and compute the "current" ETag [1] - if it differs from the one sent by the browser, go on as usually. Else issue a 304 not modified and exit [1] ETag should depend on: the requested URL, the admin cookie, date of most recent item in the current document. Having an independent/generic db subsystem is also a requirement for the favicon cache idea we've been discussing in the forums. What do you think? On 10/22/05, Sameer D'Costa <sameerslists at gmail.com> wrote: > Hello, > > I have another optimization to suggest... This will not have a dramatic > impact on load times like theme-caching but nonetheless it is still > significant. > > The basic idea is that if the browser sends a matching Etag then the > script should return the correct response code and then quit. This should > all be done before statements like require_once("init.php"); which take a > alot of time to be parsed if init.php needs to be loaded and then parsed. > (nearly 0.5 seconds on my server). This parsing is done every single > request. So if I load a gregarius page, depending on my config, it also > loads ajax.php?js plugins/delicious.php?deljs > plugins/dblclicktoread.php?dcljs and each of them load init.php in turn > before checking to see if the Etag matches. You do not save 1.5 seconds > because all these requests are done in parallel. However the load on the > server is much less and everything is spiffier. > > If no one has any objections, I will make the necessary changes to the > code. Php is really bad at caching things. A php caching/compiling system > like the zend-optimizer or apc or something would speed up gregarius > tremendously. Has anyone tried doing this? Dreamhost.com has compiled in > support for a zend-decoder. However zend encoders are very expensive. If > someone has access to one and is willing to use it for this project, we > could distribute compiled versions of the gregarius code that would run > much faster than normal. (I estimate 30 - 50% faster). The other option > would be to use a free alternative like apc or mmcache, however I dont > think it is widely supported by shared hosts. > > > Sameer > _______________________________________________ > gregarius-dev mailing list > gregarius-dev at sinless.org > http://sinless.org/mailman/listinfo/gregarius-dev >