Marco, this idea of a db subsystem is a good idea. However it needs to be lean and mean. Even the ajax callbacks could try to use it if they have something quick to do. (like marking an item as read). Sameer On Sat, Oct 22, 2005 at 08:20:15PM +0200, Marco Bonetti wrote: > Date: Sat, 22 Oct 2005 20:20:15 +0200 > From: Marco Bonetti <mbonetti at gmail.com> > To: gregarius-dev at sinless.org > Subject: Re: [greg-dev] Etag optimization > Reply-To: gregarius-dev at sinless.org > > 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 > > > > _______________________________________________ > gregarius-dev mailing list > gregarius-dev at sinless.org > http://sinless.org/mailman/listinfo/gregarius-dev