On Thu, 2007-03-08 at 01:33 -0500, Jeremy Bowers wrote: > Malcolm Tredinnick wrote: > > Since we already have middleware for attaching ETags (CommonMiddleware) > > and supporting conditional GETs (ConditionalGetMiddleware), it would be > > nice to work out why they aren't just doing the right thing here. > I found ConditionalGetMiddleware before I wrote my extra view. > > My problem with the CGM is that *first* it completely and totally does > the work of generating the RSS page, and then, only just barely before > we're about to send it out, decides to throw it away and return a 304. > It helps with bandwidth, it doesn't help with the CPU time to generate > the RSS feed in the first place.
Could you make some timings to show the difference between retrieving all the objects for a feed (which you need to do to establish whether it's changed) and retrieving all the objects and constructing the feed? The extra overhead of turning objects into a sequence of bytes isn't that huge as a proportion of the overall time -- I measured it for my own feed examples when working on some syndication problems last year and the generation was very short when compared to the database interaction and pushing out the data via the network, except when I had quite tiny datasets or very complex transformations in templates. The former is ignorable, since the total time is so small, whilst the latter is atypical for feeds. It would be interesting to see if that (the timing ratios) has changed much. There is some consistent logic supporting things like the ConditionalGetMiddleware: content generation is typically small (timewise) compared to content shipping and database retrieval. Until we've established where the real bottleneck is, it's not worth worrying too much about whether to move some middleware computation further down the stack. I think a bunch of the things you're talking about can be done by modifying contrib.syndication.views.feed() so that more return options are handled. Views can already jump out early with their own HTTP response codes and/or tweak their HTTP headers. So, if that does turn out to be the bottleneck, it should be easy to change without a major redesign. In fact, it's easy enough to use now because that view is only a dozen lines of code, so replacing it with a custom version is encouraged, if needed. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
