Whoa ! That sort of a situation in in my experience extremely common; e.g.
a URL flashed in a TV or Advert - or during a soap/talk show to 'vote' or
something. Bazillions of people on crappy modem links going on line and
fetching too-big-an images as the producers of the TV show think that you
On Fri, 12 Apr 2002 [EMAIL PROTECTED] wrote:
or the POS systems at the end of the day. Even the newspaper site I used
to work for had regular peaks which where about 150-250x higher during
predicatable 15-30 minute time slots; than the average - and the median
was well below that.
I said
Rose, Billy [EMAIL PROTECTED] writes:
Would the solution in my last email do what you are looking for?
Perhaps... But I'm the moron that is hesitant regarding drastic
changes here so I'm probably not the right person to sell your design
to right now :)
--
Jeff Trawick | [EMAIL PROTECTED]
But this bites
1) when there is just one child process (wasted syscall)
2) because it would normally go faster if the listener could stay
just
ahead of the workers so that workers can dequeue new work when
they
finish with the old without having to wait on the listener
2:49 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] convert worker MPM to leader/followers design
Rose, Billy wrote:
Would the solution in my last email do what you are looking for?
My one concern with your solution is that it puts a queue in the
httpd child processes. I think
On Thu, Apr 11, 2002 at 03:04:27PM -0400, Bill Stoddard wrote:
I am not an expert on the worker MPM but I don't think that is an accurate
statement
of
the problem. The accept thread uses ap_queue_push() to enqueue a socket for the
worker
threads. ap_queue_push() will block if the queue
Now I know I'm missing something here, so maybe you can fill in the
blanks for me. This doesn't seem like a problem that would hang the
entire server or put a hard limit on the number of concurrent connections
(across processes). I would expect a finishing worker thread to return
to the queue
Aaron Bannert wrote:
On Thu, Apr 11, 2002 at 02:09:27PM -0700, Brian Pane wrote:
The problem isn't that the busy worker threads will never become unbusy
and pick up new work from the queue. If the queue is full, and the listener
is blocked, the listener will (with the current code) be properly
Brian Pane wrote:
While flood definitely has more concurrency, I don't think the
performance
problem in this test case was ab's fault. From what I was able to
observe
It's also worth noting that the performance was fine when
I used ab with prefork and leader/follower; only with worker
Ok, now we're on the same page. I see this as a problem as well, but I
don't think this is what is causing the problem described earlier in this
thread. Considering how unlikely it is that all of the threads on one
process are on long-lived connections, I don't see this as a critical
On Thu, Apr 11, 2002 at 03:27:23PM -0700, Roy T. Fielding wrote:
Ok, now we're on the same page. I see this as a problem as well, but I
don't think this is what is causing the problem described earlier in this
thread. Considering how unlikely it is that all of the threads on one
process are
On Thu, 11 Apr 2002, Ryan Bloom wrote:
And you can always play some games with the counters to enable you
to accept a few additional connections (however you define 'few')
in order to keep some work in the queue.
It just is hard to think about what few should be given that there
Cliff Woolley wrote:
On Thu, 11 Apr 2002, Aaron Bannert wrote:
Under typical conditions, long-running and short-running requests will
be distributed throughout the children. In order for this scenario to
occur, all M threads in a child would have to be in use by a long-lived
connection.
On Thu, Apr 11, 2002 at 04:57:23PM -0700, Brian Pane wrote:
On the contrary, production servers sometimes have *huge* discontinuities
in the number of concurrent connections. Think about what happens to the
connection rate at an online brokerage every day at the instant when the
stock
Justin Erenkrantz wrote:
Can't we just add in the extra mutex check to worker and move on?
(i.e. don't call accept() when the worker queue is empty).
+1
Adding the mutex check will fix one of the three problems in worker that
I know of. The other two--the large-grained overhead of forking a
Aaron Bannert wrote:
Back then we had the POD and at least one listener, which essentially
caused us to never use S_L_U_A, meaning we always had an accept mutex.
Now that that's been corrected, the problem with the we can accept
more connections than we can immediately process is showing up
Please let's not get in any hurry replacing worker with this. worker
has problems but it is good enough to ship, and I'd rather see
incremental improvements to it since what we need now (IMO) is the
ability to get new GA releases out the door fairly quickly as our user
base ramps up and we fix
: Wednesday, April 10, 2002 12:51 AM
To: [EMAIL PROTECTED]
Subject: [PATCH] convert worker MPM to leader/followers design
Based on the slow Apache 2.0 thread earlier today,
and my observation therein that it's possible for a
worker child process to block on a full file descriptor
queue (all
Jeff Trawick wrote:
Please let's not get in any hurry replacing worker with this. worker
has problems but it is good enough to ship, and I'd rather see
incremental improvements to it since what we need now (IMO) is the
ability to get new GA releases out the door fairly quickly as our user
base
On Wed, Apr 10, 2002 at 09:44:04AM -0700, Aaron Bannert wrote:
Of course. I'm saying:
server/mpm/experimental/leader-follower
server/mpm/experimental/perchild
server/mpm/experimental/door
+1.
As long as we can do --with-mpm=perchild. I think we can get the
m4 macros to handle that.
I'm much more +1 in making it a different/additional MPM, especially
at this stage.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society that will trade a little liberty for a
21 matches
Mail list logo
