Malcolm Tredinnick wrote: For concreteness, I've added a ticket and there is a code-only patch at http://code.djangoproject.com/attachment/ticket/3680/cache.control.on.syndication.code.only.diff . The patch is exceedingly lightly tested (I've only smoke tested it on a local dev box, and I haven't tested cache_control_from_bits at all), it's just for discussion. > 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. > I understand what you're getting at, but the value of benchmarking something where there can be arbitrary client code is dubious. It's questionable how to even go about that, because one site will be dumping text directly out of the database and another site may be performing shockingly expensive computations. (Some of them may even be as the result of bad programming.)
The people who will desperately need something like this are also the ones likely to have more complicated feeds than "dump the title out of these rows in the DB", big sites. However, you've raised a good point w.r.t. database access, so I did go ahead and add the hook to determine ETag and Last-Modified before even hitting the DB. Perhaps you pull this from a cache. In that case, a no-change RSS hit is no database hits at all. > There is some consistent logic supporting things like the > ConditionalGetMiddleware: content generation is typically small > (timewise) compared to content shipping and database retrieval. I find this logic questionable. It's the non-typical cases where it is expensive where it is disproportionately important. If content generation is dirt cheap, which implies small content too (as simply dealing with large strings requires time to send them), then caching is worthless in the first place. Correct caching comes into play exactly when content generation *isn't* cheap (which it isn't always) or for large files. > 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. I don't know what you mean by this; return values from what? contrib.syndication.views.feed (at least prior to my patch) never calls any user code. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
