On Tue, 16 Oct 2007 07:52:19 -0700 "Brian Williams" <[EMAIL PROTECTED]> wrote:
> Just to clarify, we were accessing a web service that typically returns > results in < 1 second. But due to network issues out of our control, these > requests were going into a black hole, and waiting for tcp timeouts. > Admittedly, since this was to an external service, we could shift to a model > where all updates are asynchronous, but this doesn't help in the cases that > paul mentions, such as a slower reporting queries or programmer error slow > actions which then end up degrading the experience for all users to the > site. There's also an odd thing about performance: users perceive the range of response times as "slow" and not the mean. I have no idea why, but I've seen it over and over again. You'll take a system that has a mean perf of 2 seconds, but a range of .5 to 10 seconds and they think it's "slow". Tune the system so that it has 3 second mean perf, but only a range of 2 to 4 seconds and they think it's "fast as hell". But yes, if the service isn't under your control than you'll get hit by this over and over. It's better to setup an "async firewall" both in the service layer and in your UI so that they don't deal with things that are potentially variable. > Assuming we did switch to an asynchronous model, I would think it would be > more like - show me latest FOO, trigger backend update to get latest FOO, > return last cached FOO. Or if you know what FOO is, you periodically > update it, and don't bother triggering an update. There's a few general approaches you can try depending on the type of application you've got and what you can do with the UI. I like to generally categorize them into the "polling" or "inbox" methods. In polling, your controllers have four general actions to deal with the request: submit, poll, cancel, get. In this one, the user submits their request like normal, and you display a "Waiting for this to happen dude..." message. Your submit action builds the request and hands it to some service that does the real work (like backgroundrb) then returns the waiting message immediately. The waiting page then simply has a bit of ajaxy good javascript that hits the poll method to see if it's done yet, and updates a spinner or something. If you want a cancel link on the waiting page, then cancel would abort, tell the backgroundrb to stop, and shunt the user off to the end. Finally, when the poll method says it's done, you redirect to the "get" action to retrieve the final result. There's many variations on this depending on the type of tech you have, and typically works best for situations where the user will eventually see something, and they shouldn't go off doing other things. Such as in a strict biz process where they MUST complete this task before moving on (like in looking up a flight on a reservation system). In the "inbox" method (or email method) you just adopt the tried and true method of having an inbox and outbox. Users get a way to submit requests. That goes in the outbox. They can then see all the pending stuff. You then have your background processor just pull things out of people's outboxes, process them, and put the results in the inbox. Simple, and the UI for this means you have lots of chances to give them something else to do. The nice thing about this approach is the user doesn't have to care who's dealing with it, and they can even setup scheduled tasks that just get run and results are put in their inbox (which would mean no need for an outbox, but maybe a tasks folder). Canceling is simply a matter of removing it from their inbox. Really good uses for this are of course things like email and printing, but also having reports generated, conducting big number crunches, asking for analysis, etc. The trick is then to come up with a UI model that lets you use the inbox method whenever you can. Let's take the flight system as an example. Currently they have a polling method on most sites, but you could do an inbox method if the user interface was more conversational and based on secondary information about the user (like, they have Delta miles). In this model, the user puts in more information up front, or it's inferred, then says "tell me what you can find for me." The system uses all its power to go out and look for a flight potentially taking days, and simply putting status or results in the person's inbox for review or acceptance. The user would have to understand this UI approach and see an advantage to it, so if the results weren't better than just a quick query via polling it's pointless. A nice advantage of this is the user can train whatever engine you use the same way they train a Bayes classifier. Imagine if the above reservation system puts potential flights in your inbox, and you go in and just smack a "hell no/maybe so/more like this" button. This trains the flight reservation finding engine to give you better and better results until it finds what you want. Keep this information around and eventually the user will think your flight system is absolutely perfect. The test that you've got an "inbox" method right for a flight reservation system is if people can reserve flights they want via txt message off their phones over the course of a day. Another place for this would be in a movie site like Netflix. Instead of saying genres and exact movies, you go in and give demographic information as well as some movies you like. After this initial training, you put out requests for things like "Give me movies I might like that are sad." Netflix makes a "folder" for this called "movies that are sad" and starts to fill it what it thinks you might like. It actually doesn't know, but as the user classifies what is sad or not, netflix begins to learn more and gives better sad movie results. Eventually users are just getting movies that they've pre-classified and don't even bother searching. And as usual, I'll put my disclaimer that this isn't a boolean decision or that these are the only two solutions. In fact, combining the above for a flight reservation system would be a powerful metaphor if you could figure it out without confusing people. Hope that helps. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
