On Tue, 16 Oct 2007 12:49:51 +0100 Paul Butcher <[EMAIL PROTECTED]> wrote:
> On 16 Oct 2007, at 06:49, Zed A. Shaw wrote: > > On Mon, 15 Oct 2007 16:43:34 -0700 > > "Brian Williams" <[EMAIL PROTECTED]> wrote: > > > >> We recently ran into exactly this issue. Some rails requests were > >> making > >> external requests that were taking 5 minutes (networking issues > >> out of our > >> control). > > > > Now that's a design flaw. If you're expecting the UI user to wait > > for a backend request that takes 5 minutes then you need to > > redesign the workflow and interface. Do it like asynchronous email > > where the use "sends a request", "awaits a reply", "reads the > > reply", and doesn't deal with the backend processing chain of events. > > Zed, you're being obtuse. Of course that isn't what Brian means. What > he's doing is giving a pathological example to illustrate just how > badly the mod_proxy_balancer/mongrel/rails combination behaves when > things go wrong. > > Yes, you can mask the problem to some extent by mucking about with > your application (and in fact that's what we've done here), but > that's missing the point. No, as usual performance panic has set in and you're not looking at the problem in the best way to solve it. EVERYTHING takes time. No amount of super fast assembler based multiplexed evented code will get around that. In his example he also was relying on an external service. It is a *classic* mistake to make the user wait for a remote service and all of your backend processes to finish before they see the end of the HTTP request. What people constantly do though, is they assume that the boundary of their transactions must also match the single boundary of one HTTP request. If you break this so that presentation of the process is decoupled from the actual process then you don't have a problem of the user eating up a web server. But, I'm sure nobody will ever convince programmers of this. They love to run around "performance tuning" stuff instead of just redesigning the system to it appears fast. -- 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
