On Fri, May 30, 2008 at 12:49 AM, Graham Dumpleton
<[EMAIL PROTECTED]> wrote:
>
> On May 30, 12:56 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
>> 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?
>
> For mod_wsgi at least, it is a bit pendantic and errs on the side of
> logging such events on the basis that in some cases it may actually be
> because of problems in code and/or the user may want to know.
>
> There is an issue for mod_wsgi related to this where speculated that
> it could be made less noisy on such issues where it makes sense:
>
> http://code.google.com/p/modwsgi/issues/detail?id=29
>
> and/or whether the messages are displayed dependent on logging levels.
>
> At the time it was low priority and haven't since had a chance to get
> around to looking at it more closely, but will be doing so in next
> round of code changes.
>From a couple years of experience, here's the code that ended up in
Aquarium's Web server, glass. You're welcome to take it for Pylons or
Paster if you find it useful.
def is_disconnect_error(self, e):
"""Is ``e`` an error like ``errno.EPIPE`` or ``errno.ECONNRESET``?
Various types of sockets might represent disconnect errors differently.
Hopefully, one of the ways I've coded will apply.
"""
if (isinstance(e, socket.error) or
isinstance(e, exceptions.OSError) or
isinstance(e, exceptions.IOError)):
errnos = [errno.EPIPE, errno.ECONNRESET]
if len(e.args) and e.args[0] in errnos:
return True
if getattr(e, "errno", None) in errnos:
return True
return False
Best Regards,
-jj
--
I, for one, welcome our new Facebook overlords!
http://jjinux.blogspot.com/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
