httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Burry" <dbu...@tagnet.org>
Subject Re: [STATUS] (httpd-2.0) Wed Oct 23 23:45:19 EDT 2002
Date Thu, 24 Oct 2002 21:42:17 GMT
----- Original Message -----
From: "Bojan Smojver" <bojan@rexursive.com>


> On Fri, 2002-10-25 at 03:31, David Burry wrote:
> > Is it possible to get some of the fixes to mod_logio committed?
Wouldn't
> > everyone agree that the current logging of the outgoing bytes is
incorrect
> > behavior?  Currently it logs the full file size (plus headers) even if
it
> > gets cut off in the middle, instead of the actual number of bytes sent.
> > I've seen several patches to fix this but very little comment on it...
I've
> > seen lots of comments that it can't be done without major
rearchitecting,
> > but Bojan seems to have done it without that by breaking pipelining, am
I
> > correct?
>
> Actually, the last patch I sent contains one snag I'm still working on.
> It breaks the core's connection configuration structure, which gets
> attached to c->conn_config. However, I think I can get around that by
> using an optional function. As the matter of fact, I'm working on it
> right now.

I see.. ok, I'll keep waiting patiently...

> > Since I depend on correct outgoing byte count logging to see how many
people
> > sucessfully download files, I can live with broken pipelining for now in
> > 2.0, currently I've had to roll back to Apache 1.3 and put in 3 times as
> > many machines (12 instead of 4)....  I'd really like to return those 8
> > borrowed machines someday and be able to upgrade to 2.0... but can't do
that
> > in the current broken log state.
>
> Glad to hear Apache 2.0 makes a huge performance difference. Not so glad
> to hear you had to resort to going back to 1.3. The only thing I can
> promise is a patch using optional function (this should guarantee
> compatibility of core between 43 and 44 and no MMN bump) during the day
> (Sydney time). It's up to the committers to review and, if they like,
> commit.

The memory savings is quite significant, and I'll admit that the 8 extra
machines are smaller than the original 4 so it's not exactly 3 times better
cpu-wise...  the memory caching is where the largest savings comes with disk
IO, we have a very high traffic site--usually 3 terabytes transferred per
day, last few days have been more like 5 terabytes due to a new release.

> PS. By the number of messages on the list I'm guessing committers must
> be rather busy on their real jobs these days. Unfortunately there is no
> way of speeding things up, given this is volunteer effort. Unless, of
> course, you decide to bribe some of them ;-)

Not exactly the same thing as bribing a commit, but this could get similar
results:  My manager's manager is actually not opposed to hiring a
contractor to fix this... anyone want a temporary job?  I don't know if this
is the right place to say such things, tell me if there's a better place.
When you've got millions of dollars worth of sales depending on an open
source project, throwing a little at the open source project isn't such a
big deal...  I'd gladly do it myself with my company's blessing (on the
clock, not volunteer) but I'm not a very experienced C programmer yet, more
of a Perl hacker and applications architect so far.  This little paragraph
had better not get me too flooded with resumes or flames or I'm going to
feel dumb, whatever you do don't spam this list with personal replies!   ;o)

Dave


Mime
View raw message