Perlbal - Re: perlbal(reverse proxy role) timing out for slow 'reproxy'

This is Interesting: Free IT Magazines  
Home > Archive > Perlbal > September 2007 > Re: perlbal(reverse proxy role) timing out for slow 'reproxy'





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Re: perlbal(reverse proxy role) timing out for slow 'reproxy'
dormando

2007-09-19, 1:11 am

Thanks for the test case!

I won't have time to look into this for a while, so if someone else on
the list can help out, please do!

-Dormando

Hemant Bist wrote:
> Hi, I am able to reproduce this with a simple cgi script that keeps on
> writing to stdout. (Attached). The error happens within 10 sec of the
> max_idle_timeout. I see the following messages when I set the DEBUG env
> variables.
>
> Backend Perlbal::BackendHTTP=ARRAY(0x87a13a4) is readable!
> write(Perlbal::ClientProxy=ARRAY(0x87a0a
08), <886>"
> Some Random dat...") from (Perlbal::BackendHTTP,
> /usr/share/perl5/Perlbal/BackendHTTP.pm, 562)
> Client (Perlbal::ClientProxy=ARRAY(0x87a0a08)) closing backend
> (Perlbal::BackendHTTP=ARRAY(0x87a13a4))
>
>
> ====Sample run with timeout set to 60 sec with perbal running on port
> 8090=======
> time wget http://192.168.1.52:8090/blodio/for...edirect.modperl
> --14:03:17--
> http://192.168.1.52:8090/blodio/for...edirect.modperl
> <http://192.168.1.52:8090/blodio/for...edirect.modperl>
> => `forever_internal_redirect.modperl.1'
> Connecting to 192.168.1.52:8090 <http://192.168.1.52:8090>... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/plain]
>
> [ <=> ]
> 55,818 771.43B/s
>
> 14:04:24 (856.85 B/s) - `forever_internal_redirect.modperl.1' saved [55818]
>
>
> real 1m7.116s
> user 0m0.012s
> sys 0m0.012s
>
> HB
>
> On 9/17/07, *dormando* <dormando@rydia.net <mailto:dormando@rydia.net>>
> wrote:
>
> Okay,
>
> I missed it on my first read through that area. Adjusting that variable
> should fix it for you. The latest SVN will work better since it's
> configurable.
>
> BackendHTTP.pm does the "client writing" of a response. Thinking if it'd
> still be desired behavior to ensure the client idle's been updated.
>
> Something else might still be buggy here, since I know I've done
> transfers to a client which take much longer? Can you try testing by
> reproxying a lot more data with a low timeout? Ten or thirty times more
> data than your CGI's presently sending.
>
> -Dormando
>
> Hemant Bist wrote:
> seconds
> changing
> if I hit
> backend slow
> to write
>
>



Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com