lkml.org 
[lkml]   [1999]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Preparations for ZD's upcoming Apache/Linux benchmark
Hello all, longtime lurker (vi LinuxHQ ^H^H^H^HKernalnotes mailing list page)
first time poster. :)

Jorge Gonzalez <jorgegv@icai.upco.es> wrote:

> Thomas Wouters wrote:

>> All in all, the setup gets fairly hairy, especially when you have to take
>> stupid users into account. I personally doubt the speed difference between
>>khttpd+apache and an optimized apache or zeus or other webservers is worth
>> the trouble, especially when you start taking disk and network i/o speed and
>> latency into account. I'd spend more time showing how Apache/linux
>> outperforms MS/IIS in real-world applications than confusing my own
>> supporters with FUD :-)

In my experience, "real world applications" means bunk. The magazines don't
have the time or space to do detailed explinations of _any_ topic, never mind
benchmarks. Do the test, print the numbers, declare a winner - that's the game
we're playing here.

However, I don't think we should get sucked into the "benchmark of the month"
game either. Anything we do should provide benefit to both the real-world and
the contrived benchmark schenarios. I'm pretty sure that M$ does their
homework; they pick several benchmarks they can "win" at, pipeline them, and
then release them in stages. When Competitor X is on the verge of fixing the
"problem" the previous benchmark brought to light, they release the next one
and hammer them again. Against a commercial software company (with limited
manpower and a lot bet against future sales) this tactic is deadly. Chase your
tail long enough, and you run out of money.

We may not be in danger of running out of money, but we do run the risk of
fragmenting developer focus to the point where nothing gets done anymore.

If a benchmark reveals honest-to-Dog bugs, we win by fixing them. If they
reveal honest-to-Dog design flaws, we win by making a better design (or
by throwing out an old and crufty one)

That's a series of pretty spectacularly obvious statements for this crowd,
I know, but it bears repeating. Sometimes the obvious isn't. :)

>> But then, i might be wrong. i haven't seen much info on howmuch faster
>> khttpd could become, compared to a fast but simple httpd (and i gather there
>> isn't much, yet.) If the benifit is large enough, users will cope :-)

> I do _really_ agree with this. I think the people would be better
> helping in doing a well-behaved multithreaded (not multiprocess) Apache.
> Someone said two days ago that if we can not design eficient servers in
> user-space then it's the OS that needs to be fixed, and not the server
> moved into kernel space.

I'm halfway with you. A better Apache is "better" than trying to make Apache
into a kernel module.

That's not to say that enhancements to both can't go hand-in-hand - the
"wake-one thundering herd" fix is a good example.

Having said all this, I think the khttpd is a good idea for a limited set of
circumstances. If all you want is static information, with no authentication
or authorization or any other silliness, the kernel handles the request. As
soon as you do anything else - boom, hand it off to Apache. Khttpd winds
up being a kind of limited-scope Apache (or for that matter, your httpd of
choice) accelerator module. I think that the case of images alone justifies
khttpd's existence.

However, the key is that Apache et. al. must adapt to khttpd's interface,
not the other way around. Keep khttpd as simple, sleek, fast, and
lightweight as possible, and let Apache do all the hard stuff.

That probably (IMHO) boils down to a khttpd.conf file that is a list of
portions of the http filesystem tree that khttpd is responsible for. If an
incoming request maps into this space, khttpd serves it, otherwise,
pass it through. In this space, you get no .htaccess files, no SSI, no CGI,
NOTHING (except a log file, and what should happen here is that khttpd
should write its logs to some sort of socket into Apache and let Apache
handle the formatting and actual disk access)

Does this limit what you can do with khttpd? You bet. But it keeps khttpd
small and light, it works well for benchmarks like Mindcraft's, and it gives
a Webmaster a tool for accelerating certain aspects of his server's
performance if it matches the profile of what khttpd is desiged to
accelerate. Win, win, win.

Now how about something _really_ useful, like a kslapd? :)

DG
LDAP Directory Master
DaimlerChrysler Corporation

Note: I'm not subscribed directly to the list, so I won't see responses until
they show up on Kernelnotes. If you want faster response from me, please
cc:dg50@daimlerchrysler.com.





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.042 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site