Return-Path: 
 <dev-return-76697-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
X-Original-To: apmail-httpd-dev-archive@www.apache.org
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id A5E27EF0B
	for <apmail-httpd-dev-archive@www.apache.org>;
 Tue, 15 Jan 2013 10:37:15 +0000 (UTC)
Received: (qmail 95155 invoked by uid 500); 15 Jan 2013 10:37:14 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 94858 invoked by uid 500); 15 Jan 2013 10:37:09 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 94828 invoked by uid 99); 15 Jan 2013 10:37:08 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2013 10:37:08 +0000
X-ASF-Spam-Status: No, hits=-2.3 required=5.0
	tests=RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [130.239.18.156] (HELO mail.acc.umu.se) (130.239.18.156)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2013 10:37:02 +0000
Received: from localhost (localhost [127.0.0.1])
	by amavisd-new (Postfix) with ESMTP id F28B7931
	for <dev@httpd.apache.org>; Tue, 15 Jan 2013 11:36:41 +0100 (MET)
X-Virus-Scanned: amavisd-new at acc.umu.se
Received: by mail.acc.umu.se (Postfix, from userid 12143)
	id 314AC930; Tue, 15 Jan 2013 11:36:41 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by mail.acc.umu.se (Postfix) with ESMTP id 2AD0792F
	for <dev@httpd.apache.org>; Tue, 15 Jan 2013 11:36:41 +0100 (MET)
Date: Tue, 15 Jan 2013 11:36:41 +0100 (MET)
From: Niklas Edmundsson <nikke@acc.umu.se>
To: dev@httpd.apache.org
Subject: Re: event mpm and mod_status
In-Reply-To: <201301121804.25143.sf@sfritsch.de>
Message-ID: <alpine.GSO.2.02.1301151127490.29468@hatchepsut.acc.umu.se>
References: 
 <CAFE37cgYr0JOKhR5C8bPYhOqwY-zqVj177A=Swx6dU_YzAcdpA@mail.gmail.com>
 <201301072333.25413.sf@sfritsch.de>
 <alpine.GSO.2.02.1301101525280.27854@hatchepsut.acc.umu.se>
 <201301121804.25143.sf@sfritsch.de>
User-Agent: Alpine 2.02 (GSO 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Checked: Checked by ClamAV on apache.org

On Sat, 12 Jan 2013, Stefan Fritsch wrote:

> On Thursday 10 January 2013, Niklas Edmundsson wrote:
>> To reiterate back to the event mpm / mod_status integration, are
>> there any work in progress on implementing a more verbose status
>> display for the event mpm? I'm thinking of something that can show
>> all requests currently being processed like we have today for
>> prefork/worker. The current "thread status" thingie is probably
>> interesting too, but more from a developer/server diag point of
>> view.

<snip>

> I am not aware of anyone working on this.

OK.

> I agree that mod_socache may be a bit heavy-weight for this, but one
> would need to test that.

My guess is that it's the one-big-lock requirement that bogs this 
down for high request/s rates, but for us it might be good enough.

> There is also mod_slotmem_shm, but AFAICS
> that requires to know the size in advance. So one would have to
> allocate AsyncRequestWorkerFactor times (max number of threads) slots
> to have one slot per connection.

I'll investigate a bit when time allows. Part of the problem is to 
find something useful to use as an identifier/index, process/thread is 
obviously not enough.

> This would still not give the full picture, because with pipelining,
> there can be several (5 or 6, I think) requests active on one
> connection: zero or one being processed by a worker and the rest doing
> write completion. I am not sure how much effort one should put into
> displaying that correctly in mod_status, though.

Given that all file delivery will be done by write completion I think 
we'll want this to be rather accurate, at least for the connections 
doing write completion (think a server being overloaded serving DVD 
images, it gets easier to diagnose if you can easily figure out the 
culprit).

/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  If it's useless, it will have to be documented.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=