Hi Erik - Yes I meant to cc the list! :-)
OK - that's what I'm coming to the conclusion as well that this is the way siege behaves because I was able to get a request through just fine in a sub-second response while siege was hung. I'm glad you're seeing this behavior as well so my load balancer is probably working. Thanks very much for looking into this. Mike On Thu, Feb 14, 2008 at 1:09 PM, Erik Hetzner <[EMAIL PROTECTED]> wrote: > At Thu, 14 Feb 2008 12:33:44 -0600, > "Michael Engelhart" <[EMAIL PROTECTED]> wrote: > > > > Thanks Erik for the advice and link. > > > > After modifying the load balancer to use those parameters I'm still > > seeing the behavior though: > > > > Here are a few lines of output from siege before I hit the long > > running process with my browser. It generally just repeats at about > > this pace give or take a few milliseconds: > > HTTP/1.1 200 0.18 secs: 1998 bytes ==> /trips/1 > > HTTP/1.1 200 0.20 secs: 1998 bytes ==> /trips/1 > > > > But then when I hit my browser against the long running web service > > request, siege hangs for about 20 seconds > > > > Then siege dumps the following lines all at once which says to me > > that every request was blocked until the long running process ended: > > > […] > > Hi Michael. > > (Did you mean to cc the list?) > > Anyhow, this looks like the same behavior. I think this is something > to do with the way that siege works, based on a simulation I just did > with siege on my own system. Can you get a response back from your > balancer (not from siege) when siege has hung? > > -Erik > > ;; Erik Hetzner, California Digital Library > ;; gnupg key id: 1024D/01DB07E3 > >
_______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
