The query should not take 10 seconds. People should not steal. Still,
they do, and I live with the workaround -- locking.
So, while the 10-second query is a problem, and worth solving for its
own sake, the mod_proxy_balancer solution prevents it from causing the
secondary, request queuing p
On Tue, 16 Oct 2007 14:01:16 +0100
Paul Butcher <[EMAIL PROTECTED]> wrote:
> On 16 Oct 2007, at 13:45, Zed A. Shaw wrote:
> > No, as usual performance panic has set in and you're not looking at
> > the problem in the best way to solve it.
>
> Sorry Zed, I have a great deal of respect for your w
On Tue, 16 Oct 2007 07:52:19 -0700
"Brian Williams" <[EMAIL PROTECTED]> wrote:
> Just to clarify, we were accessing a web service that typically returns
> results in < 1 second. But due to network issues out of our control, these
> requests were going into a black hole, and waiting for tcp timeou
Brian Williams 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). If your request got queued behind one of these
stuck mongrels, the experience was terrible. I experimented with
On 10/15/07, Zed A. Shaw <[EMAIL PROTECTED]> 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
On 16 Oct 2007, at 13:45, Zed A. Shaw wrote:
> No, as usual performance panic has set in and you're not looking at
> the problem in the best way to solve it.
Sorry Zed, I have a great deal of respect for your work and your
opinions on development. But you seem to have a blind spot here and I
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
Alexey Verkhovsky wrote:
On 10/15/07, Zed A. Shaw <[EMAIL PROTECTED]> wrote:
Tried Lucas Carlson's Dr. Proxy yet? Other solutions? Evented mongrel?
HAProxy (and some other proxies smarter than mod_proxy_balancer)
solves this problem by allowing to set the maximum number of requests
o
What settings did you use in m_p_b?
The trick to making it work was "acquire", "max", and probably "timeout".
Brian Williams 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). If
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
>> c
On 10/15/07, Zed A. Shaw <[EMAIL PROTECTED]> wrote:
>Tried Lucas Carlson's Dr. Proxy yet? Other solutions? Evented mongrel?
HAProxy (and some other proxies smarter than mod_proxy_balancer)
solves this problem by allowing to set the maximum number of requests
outstanding to any node in the cluste
> At least piling them in mongrel means some IO is getting processed.
Ok, that's the real issue then. When you have a heavy queuing
situation, Ruby can at least schedule the IO among the green threads
whereas Apache has to keep them serialized waiting for a worker to
open up.
Evan
On 10/16/07, Z
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
On Mon, 15 Oct 2007 12:51:47 -0400
"Evan Weaver" <[EMAIL PROTECTED]> wrote:
> Ah, no, they are only marked operational until the retry timeout is
> elapsed. So I guess if you had extremely small timeouts in Apache and
> Mongrel both it would work ok.
>
> Someone else respond, because clearly I do
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). If your request got queued behind one of these stuck mongrels,
the experience was terrible. I experimented with adjusting the
mod_proxy_ba
Ah, no, they are only marked operational until the retry timeout is
elapsed. So I guess if you had extremely small timeouts in Apache and
Mongrel both it would work ok.
Someone else respond, because clearly I don't know what I'm talking about. :)
Evan
On 10/15/07, Evan Weaver <[EMAIL PROTECTED]>
Oh, I misunderstood your code.
I don't think mod_proxy_balancer gracefully moves on so perhaps you
are right. On the other hand, I thought when a worker timed out it got
removed from the pool permanently. I can't seem to verify that one way
or the other in the Apache docs, though.
Evan
On 10/15/
But it is precisely because of mod_proxy_balancer's round-robin
algorithm that I think the fix *would* work. If we give
mod_proxy_balancer the option of timing out on connect, it will iterate
to the next mongrel instance in the pool.
Of course, I should look at Evented Mongrel, and swiftiply.
Mod_proxy_balancer is just a weighted round-robin, and doesn't
consider actual worker load, so I don't think this will help you. Have
you looked at Evented Mongrel?
Evan
On 10/15/07, Robert Mela <[EMAIL PROTECTED]> wrote:
> Rails instances themselves are almost always single-threaded, whereas
> M
Rails instances themselves are almost always single-threaded, whereas
Mongrel, and it's acceptor, are multithreaded.
In a situation with long-running Rails pages this presents a problem for
mod_proxy_balancer.
If num_processors is greater than 1 ( default: 950 ), then Mongrel will
gladly acc
20 matches
Mail list logo
