On Thu, May 29, 2008 at 4:30 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > On May 29, 7:29 pm, "Alex Marandon" <[EMAIL PROTECTED]> wrote: >> 2008/5/29 Alex Marandon <[EMAIL PROTECTED]>: >> >> >> >> > 2008/5/28 SamDonaldson <[EMAIL PROTECTED]>: >> >> Running ab benchmark tests revealed many requests were failing. >> >> Should I be starting MORE Paster processes to handle the load? Is >> >> this the right thing to do, or is the Paster (SCGI) process itself >> >> multi-threaded to handle such synchronous requests. Say the Paster >> >> process is doing some I/O (SQL query through sqlalchemy), would that >> >> process block and would other requests wait, or would they get >> >> serviced? >> >> > Hi Sam, >> >> > According >> > tohttp://wiki.pylonshq.com/display/pylonscookbook/Pylons+Execution+Anal... >> > paster is multithreaded. It should be easy to test. Hit a controller >> > action that sleeps for 10 seconds and see if you can still make >> > requests to other actions. I actually need to test for myself as soon >> > as I get to work. As for why you get failed requests, I don't know. >> >> class FooController(BaseController): >> >> def bla(self): >> return 'Hello World! %s' % time.time() >> >> def slow_bla(self): >> time.sleep(10) >> return 'Hello slow World!' >> >> With something like that, manual testing works just fine (ie: I'm able >> to hit the action bla as many times as I want while the action >> slow_bla is still serving). >> >> When testing with ab though, I do get failed requests, but I actually >> get even more failed requests with Apache/mod_wsgi. > > What options are you using to 'ab'? > > The 'ab' program can give a perception of errors, normally manifesting > as lots of exceptions on server side in log file, if you use > concurrent requests. This occurs because it only stops when it > receives responses for the number of requests you tell it to make. > With a request handler that takes a long time, because of a sleep() > call, the 'ab' program can actually issue more requests than you tell > it to. When it does receive responses for the number you told it, it > will simply shutdown the connections for all the additional requests > it made which it hasn't yet received a response. The result of this is > that on the server side it will see a bunch of closed connections > causing failures to be able to write the responses for the additional > requests. > > The end result is that one thinks that the hosting mechanism is having > problems, when in fact it is due to how the 'ab' program works.
That's akin to the user pressing the Stop button in the browser. I get a "connection reset" line for that in my Quixote apps but not in my Pylons app. I assumed Pylons just ignored the exceptions because it's not really an error if the client goes away. But in any case, I don't get socket errors in my Pylons error log, and I can't assume that's because nobody ever presses Stop. So if Alex is getting such errors, the question is why the difference in behavior? -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
