On Fri, 21 Nov 2003, Bruce Van Allen wrote: > Most of my web apps have 100% dynamic output, and the main way I cope > with timeout issues is to keep things fast. It could be that my > experience is from particular combinations of web server, web browser, > and my scripts' operations. Or maybe I've drawn a wrong conclusion.
I think that's it right there. If everything is *really* dynamic, and you can't even know a priori if the result is going to be simple html, some other content type, a redirect, or some other server response, then okay, I can see delaying output. I think though that I'd try to write things in such a way that that particular decision is as front-loaded as possible -- that is, try to figure out which branch you're going to end up following before doing anything else, then try to let the web client know if possible, then get on to doing the rest of the output. There are also simple html tricks that can help perceived speeds, e.g. if your page layout depends on tables -- hopefully not these days, but I'm sure it still happens -- then put some content before the tables, or try to break the page into a vertical stack of tables or something along those lines. That way it at least *looks* like something is happening to the web user. I'd assume that with CSS layouts you don't need to be nearly as "clever" in page construction, but haven't actually seen any tests to verify this assumption. > To be more specific, I noticed inconsistencies with some web apps that > logged state & activity; That is a valid point; I don't know what the best habit there would be. If it's not too noisy, I personally would consider logging twice for anything that I expected to take a long time -- first as a ping, with maybe the parameters to be processed (if that's a reasonable amount of data to log), and then again after processing with the finished results. If you want to get real fancy, you could get into database style ACID techniques, where everything is handled as a transaction and you put in mechanisms for things like commits & rollbacks, and various commit logs and so on -- but then at that point, the application may be complex enough that it may start to make sense to actually let a database engine start doing the work for you rather than hand-rolling such mechanisms. Maybe. > Thinking about it, another reason I habitually delay printing even http > headers is that a script's result state might be expressed as a > redirect, an image, or as plain text, rather than html. See above about branching; that's how I think I'd try to cope with this. > OTOH, a quick > look shows that I have a bunch of CGIs deployed whose first action is to > print the usual "Content-type: text/html\n\n" line, long before doing > anything with the input or any data, which follows the standard CGI > advice. ...and that, generally, is my approach. Print the headers, try to print the header part of the html (title, stylesheet, etc), and then just the most generic part of the top of the actual page -- that for the visual feedback for the user more than anything else. > So, no, Chris, you're not wrong. But my "what works" practice is to do > as much as possible before output. Maybe it's more correct to say > "before final output" but I don't know how the webserver would know that > a script has no more output. Is it because the client breaks the > connection once it gets the html output? I got an interesting mail about this offlist which I won't try to quote or summarize unless the sender minds. Andrew? Care to comment? > Again, perhaps someone who understand more about how Apache (or IIS) > controls CGI execution could comment. In general, I think your opening paragraph nailed it: there are a lot of variables to consider, and there may be no general "best practice". In many cases, my hunch is still to send data as you have it, but there can obviously be cases where this doesn't work in practice. As with everything else in web programming, the only real rule of thumb is probably just one word: "Test." -- Chris Devers still baffled by the apache::dbi errors
