I just committed phase two of the cache system: there is a new "cache" table that holds the "global last update" value which is used to compute the ETag key. Whenever data changes on the database we should call rss_invalidate_cache() to update the above timestamp. As of now the cache gets invalidated when: - you mark a feed/item/folder/everything as read, - you update tags for an item - you update your feeds - change the sidecolumn view I'm probably missing a couple places, but those are easily fixed when we spot them. Phase three will see the implementation of the Cache-control headers Sameer quite wisely suggested. And then we'll be ready for blobbed-favicons :) -m > > 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 > _______________________________________________ > gregarius-dev mailing list > gregarius-dev at sinless.org > http://sinless.org/mailman/listinfo/gregarius-dev >