>> Then we decided to switch persistant connection off... But boa still wins.
>>
>> What is wrong here? I would expect transferates of a 3-4 megabytes over a
>> localhost interface. The file is certainly in some kind of cache.
> This just goes on to show that khttpd is unnecessary kernel bloat and can be
> "just as well" handled by a userspace application, minus some rather very
> special cases which do not justify its inclusion into the main kernel.
Well, this test only shows khttpd does badly for localhost, as it doesn't give
userspace a fair chance to schedule. It's too bad Christoph didn't test it
with the persistent-connections patch that didn't get sent to Linus due to
the "no more features" freeze (I don't exactly remember which of the freezes
though).
Regarding wether either khttpd or TuX should be in the kernel: I take it
that it is your oppinion that neither should be in the kernel. I disagree
with that and I think having a http-server-engine (or even a more generic
file-serving engine) in the kernel can make sense for high-end uses. The
average desktop-user doesn't profit from it, sure. But that also holds for
things like hardware-raid or even SCSI. We still want those in though.
Wether TuX or khttpd should be in... well. I agree with DaveM that TuX is
certainly the "next and better" generation, and I look forward to working
with Ingo and others on it.
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/