Hi Marco,
I have a couple of thoughts inline,.,
> 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)
We can use this for the static javascript in ajax.php as well. What about
using the Cache-control header in conjunction with eTags? That would be
more effective, because the javascript/css does not change until you
upgrade Gregarius, so we can tell the browser that it is fresh for a
while and when it comes to revalidate we can use an Etag. A global Etag
creates a problem here...
> So I think we'll need an additional 'cache' table which will hold:
>
> a) the favicon cache (in a blob)
Again the Cache-control header will help alot over here as we spit out
favicons with long time freshness.
> b) magpie's cache (?)
jrobbins had some thoughts about this on the forum. Is he on the dev
mailing list too? I have mixed feelings about this. On one hand we avoid
the permissions problems and on the other we lose the ability for
multiple gregarius installations to share the magpie 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
I think this makes sense. However IMO there are two problems. One is to
deal with the pseudo static files created by the javascript/css that the
php scripts spit out (eg plugins/ajax.php?js). These files change only
when gregarius is upgraded. The other is to deal with the dynamic scripts
that read from the database and have a way to determine when they are
going to change their output. A global Etag handler would solve the
second problem very well but it would not be so efficient at solving the
first.
> 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)
I wonder too...
> 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
> >
>
> _______________________________________________
> gregarius-dev mailing list
> gregarius-dev at sinless.org
> http://sinless.org/mailman/listinfo/gregarius-dev