On Thu, Jan 28, 2010, Petr Baudis wrote: > On Mon, Jan 25, 2010 at 12:32:37PM -0800, J.H. wrote: > > This does 2 things in the end: > > > > 1) means there's only 1 copy of the page ever being generated, thus > > meaning there isn't extraneous and dangerous disk i/o going on on the system > > But this has nothing to do with what you _do_ when there are multiple > requests, whether you do the same as if caching was disabled (hang until > content is generated) or doing something novel (creating redirects > through "Generating..." page). > > > 2) prevents a user from reporting to the website that it's broken by > > giving them a visual que that things aren't broken. > > But this has nothing to do with caching per se, right? I think it > actually makes _no difference_ if caching is enabled or not to this > problem, or am I missing something? > > > My point is, I guess, that showing the Generating page doesn't seem to > have actually anything to do with the caching itself? The point is that without caching it is easy to streaming response, and to consider early parts of page (like page header, generated before any heavy work) to serve as activity indicator. With caching it is difficult to have streaming response, both from technical point of view (writer must generate to client and to cache simultaneously, readers must know when writer finished work to close connection), and from robustness point of view (what happens if writer is interrupted / killed before finishing generating output). With "generate then display" (which is not exclusive to caching, and is another possible way of generating content even without caching) we rather need some kind of activity indicator like "Generating..." page. I think that "Generating..." page can be improved in two ways: * Show "Generating..." page only if we are waiting for response for more than one second. This might need mucking with alarms, as I think that sleep 1 before $self->generating_info(...) would be not a good solution. * Stream response (using PerlIO::tee layer from PerlIO::Util, or Capture::Tiny module, or tied filehandle like in CGI::Cache) for writer (i.e. process generating data), and wait for it to be finished (perhaps with "Generating...") in readers. This way you wouldn't get "Generating..." page for rare views/URLs, and for common views/URLs there is high probability that you would not need "Generating..." page as there would be slightly stale response to serve. Of course one can implement _both_ of those solutions, i.e. wait one seconds in readers, and stream in writer. I am not sure, but there might be another issue why activity indicator is more important for the case with caching enabled. If you interrupt writer, one of readers waiting for finished data would have to take role of writer, which besides need for technical solution to this problem would mean longer wait. [..] > > > (ii) Can't the locked gitwebs do the equivalent of tail -f? > > > > Not really going to help much, most of the gitweb operations won't > > output much of anything beyond the header until it's collected all of > > the data it needs anyway and then there will be a flurry of output. It > > also means that this 'Generating...' page will only work for caching > > schemes that tail can read out of, which I'm not sure it would work all > > that well with things like memcached or a non-custom caching layer where > > we don't necessarily have direct access to the file being written to. > > > > At least the way I had it (and I'll admit I haven't read through Jakub's > > re-working of my patches so I don't know if it's still there) is that > > with background caching you only get the 'Generating...' page if it's > > new or the content is grossly out of data. If it's a popular page and > > it's not grossly out of date it shows you the 'stale' data while it > > generates the new content in the background anyway, only locking you out > > when the new file is being written. Or at least that's how I had it. > > Well, my user experience with gitweb on kernel.org is that I get > "Generating..." page all the time when I dive deep enough to the object > tree. I just find it really distracting and sometimes troublesome when > I want to wget some final object. First, the user_agent checking would help there (it's a pity that all web spiders (bots) and all non-interactive downloaders do not say what they are explicitly in User-Agent string). Second, I guess that waiting 1 second (or more) before showing "Generating..." page would help in most cases. > > I think it's fine to take in the caching support with the Generating... > page in the bundle, but I do want to declare my intention to get rid of > it later, at least for caching backends that could do without it - for > pages where content appears incrementally, tail -f, for pages where > content appears all at once, show at least the header and some "I'm > busy" notification without redirects. In the final version this should be fully configurable. Note that the series of patches I have send were just proof of concept for splitting caching patch into smaller parts / individual features. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html