From: Ken Brownfield <ken@irridia.com>
To: Dan Kegel <dank@kegel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"khttpd-users@lists.alt.org" <khttpd-users@alt.org>
Subject: Re: khttpd newbie problem
Date: Thu, 9 May 2002 00:31:55 -0500 [thread overview]
Message-ID: <20020509003155.B12672@asooo.flowerfire.com> (raw)
In-Reply-To: <3CD402D2.E3A94CA2@kegel.com> <20020505005439.GA12430@krispykreme> <3CD4C93D.E543B188@kegel.com> <20020508222119.A12672@asooo.flowerfire.com> <3CDA0876.218285C7@kegel.com>
On Wed, May 08, 2002 at 10:26:14PM -0700, Dan Kegel wrote:
| Ken Brownfield wrote:
| > khttpd is very much production quality on IA32, and has been since
| > 2.4.0-test1.
|
| It oopses readily on start/stop -- see
| http://marc.theaimsgroup.com/?l=linux-kernel&m=102068445316516&w=2
| in which DecodeHeader is called with no buffer allocated.
| Happened quite frequently during my tests. Since my patch I
| can't get it to oops on x86, but it's still oopsing on ppc405.
| So perhaps now it's production quality... but it still needs
| a bit too much babying on stop. (It'd be fairly easy to fix
| the unreliable way it senses the stop command.)
Hmm. I've had it running *hard* for two years, never seen a single oops
or glitch of any sort, kernels 2.4.0-test1 through 2.4.18. O(1),
preempt, low-latency all on at various times. All static images though,
with no pass-through.
| > TUX2 is not, however, since under load it enters a 99% CPU
| > busy loop.
|
| I checked the tux list and found the post you're taling about:
| http://marc.theaimsgroup.com/?l=tux-list&m=101420257421009&w=2
| Hmm. Well, at least it doesn't oops :-) Thanks for the warning.
Heh, no prob. The most recent version might have fixed it, although the
last time I tried TUX2 I got a hard hang... prolly O(1) but I never had
time to narrow it down.
[...]
| where foo_load is a hacked version of http_load (I think)
| which is fetching a single 128KB file over and over.
| I tried reproducing this with acme.com's http_load,
| without success so far.
Odd, seems identical to my standard traffic, though my images are in the
4-64k range. What you're seeing seems to be an interaction problem --
something different in the non-mainstream, non-x86 kernel that's
allowing khttpd to hang itself. No argument that khttpd is frightening.
[...]
| Yukky. Makes me want to go work with user-mode web servers instead.
Yeah, good luck tracking down X15. I've wanted to create a
heavily-modified apache MPM, but my time is unfortunately finite...
Apache2 on top of TUX2 would be ideal, but alas neither is quite
prime-time yet.
--
Ken.
ken@irridia.com
|
| - Dan
next prev parent reply other threads:[~2002-05-09 5:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-04 15:48 khttpd newbie problem Dan Kegel
2002-05-05 0:54 ` Anton Blanchard
2002-05-05 5:55 ` Dan Kegel
2002-05-05 11:04 ` Anton Blanchard
2002-05-09 3:21 ` Ken Brownfield
2002-05-09 5:26 ` Dan Kegel
2002-05-09 5:31 ` Ken Brownfield [this message]
2002-05-09 16:13 ` Dan Kegel
2002-05-09 5:46 ` Anton Blanchard
[not found] <200205041600.g44G0J708618@pc3-camc5-0-cust13.cam.cable.ntl.com>
2002-05-04 17:15 ` Dan Kegel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020509003155.B12672@asooo.flowerfire.com \
--to=ken@irridia.com \
--cc=dank@kegel.com \
--cc=khttpd-users@alt.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.