Well, as of [969] there is now a "global" ETag header sent out on
every request, and the database subsys has been isolated.
Plugin authors that require an ETag caching system or those pages that
do not require the full backend business to be loaded can
require_once('core.php') and then call rss_bootstrap(BOOLEAN), the
argument specifying whether the database subsys should be loaded or
not (e.g. static javascript doesn't need the db, while the favicon
cache will)
It works quite fine, up to an annoying bit: the cache is a wee too
pedantic. We are currently checking against the publication date of
the latest item to issue the ETag key (among other bits) but tagging
an item or marking it as read doesn't affect the key.
So I think we'll need an additional 'cache' table which will hold:
a) the favicon cache (in a blob)
b) magpie's cache (?)
c) a timestamp flag which will be updated whenever the data in the
database is changed: item tagging, mark as read, update. (RDBS
triggers, anyone?)
This timestamp will then be used to compute the ETag key.
Does this make sense? Does anyone see a flaw in this behavior? We
could store the timestamp in a file in Magpie's cache directory as
well, for example. (I wonder how a frequently-read-rarely-written file
on the file system compares to a database, from a performance P.O.V)
And what are your opinions on b) ?
-m
On 10/22/05, Sameer D'Costa <sameerslists at gmail.com> wrote:
> 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
> _______________________________________________
> gregarius-dev mailing list
> gregarius-dev at sinless.org
> http://sinless.org/mailman/listinfo/gregarius-dev
>