I recently compiled thttpd on RedHat Linux 5.2. It compiled fine, but
when
I execute it, it simply exits - no messages in syslog or in the log file I
direct it to. Does anyone have experience with thttpd? Can you tell me
what's going on?
TIA,
Eric
------------------------------------------------------------
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------
Most Linuxs are delivered with a broken syslog. thttpd is probably running,
try connecting to the port and see what you get.
Anyway, if you care about performance enough to be using thttpd, you should
not be using Linux. Linux's network performance is terrible. Install
FreeBSD 3.x instead.
---
Jef
Jef Poskanzer j...@acme.com http://www.acme.com/jef/
"Faith: not *wanting* to know what is true." -- Friedrich Nietzsche
Huh? What version can't drive at least a few 10M adapters at wire speed?
Perhaps you are having trouble with a particular driver or are
using an inefficient ISA card.
Les Mikesell
l...@mcs.com
http://advisor.gartner.com/n_inbox/hotcontent/hc_2121999_3.html#h8
I'll be doing my own Linux v. FreeBSD measurements in a few weeks.
I expect to see an even larger difference, since I'll use FreeBSD 3.0
instead of FreeBSD 2.2.7 - 3.0's network performance is about 40% better.
}What version can't drive at least a few 10M adapters at wire speed?
10Mbps ethernet is old hat.
}I can back that... I would't call 5 MByte/s in a ftp session exactly
}slow... done over ATM and 100BaseTx (large file, around 150 MByte,
}Linux 2.0.36 and 2.2.1-ac7).
You could only use half the 100Mpbs net then? With how many MHz?
I find that a mere 200MHz machine can fully saturate a 100MHz net,
as long as it's running FreeBSD.
}the limit was rather obviously the harddisk performance, not the network.
Well, try it again without the disk in the equation.
---
Jef
Jef Poskanzer j...@acme.com http://www.acme.com/jef/
"Never do anything if you can find someone to do it better - except
for the things you want to do most of all."
-- Thomas James
It Depends ...
You can also Have an Solaris 2.6 System with an Apache 1.3.4 Server,
that is "FAST" enough
to handle Big Websites (If 320 GB of Traffic in an Month is Enough for
you). Sure, FreeBSD
seems to be faster in networking speed, but do we need the full speed it
provides ?
In the Last 2-3 Years FreeBSD seems ever to be faster in TCP/IP
Networking as the Linux pendant.
Linux is now everywhere, many people develop for Linux, but why is the
speed of the TCP/IP Stack
not as fast as in BSD ? Maybe the Speed is not important enough.
Greetings
Robert Depenbrock
People on drugs should not post.
---
Jef
Jef Poskanzer j...@acme.com http://www.acme.com/jef/
"Our vision is to speed up time, eventually eliminating it."
-- Alex Schure
Oh, there you go, spoiling my fun.
Ok, fine. Yes, Robert is right. For almost all sites, Linux running
Apache on a 10Mbps net will be "fast enough". But remember the
original point: if you're going to use thttpd instead of Apache,
presumably you *do* care about speed, for whatever reason. Just what
that reason is doesn't matter - it's a given. And with that given,
using Linux simply doesn't make sense, since it's slow.
---
Jef
Jef Poskanzer j...@acme.com http://www.acme.com/jef/
Old soldiers never die. Young ones do.
Getting linux-2.2.0.tar.bz2 from a Pentium 166 running an ancient
Linux 2.0.34 kernel I get the following rates (file downloaded
a couple of times to make sure it was in the buffer cache):
ftp> get linux-2.2.0.tar.bz2
local: linux-2.2.0.tar.bz2 remote: linux-2.2.0.tar.bz2
200 PORT command successful.
150 Opening BINARY mode data connection for 'linux-2.2.0.tar.bz2' (10592549 bytes).
226 Transfer complete.
10592549 bytes received in 1.11 secs (9295.6 kB/s)
Doing the same from a PPro 200 running Linux 2.2.2 (2.2.5 is recent)
I get:
ftp> get linux-2.2.0.tar.bz2
local: linux-2.2.0.tar.bz2 remote: linux-2.2.0.tar.bz2
200 PORT command successful.
150 Opening BINARY mode data connection for 'linux-2.2.0.tar.bz2' (10592549 bytes).
226 Transfer complete.
10592549 bytes received in 0.96 secs (10763.2 kB/s)
I wouldn't call that bad performance.
Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?
Okay, I also replied with some numbers without bashing FreeBSD. But
this is getting ridiculous. Want to bash linux, want to bash FreeBSD,
fine. Take it to an advocacy group, don't do it here. It upsets people.
> Oh, there you go, spoiling my fun.
>
> Ok, fine. Yes, Robert is right. For almost all sites, Linux running
> Apache on a 10Mbps net will be "fast enough". But remember the
> original point: if you're going to use thttpd instead of Apache,
> presumably you *do* care about speed, for whatever reason. Just what
> that reason is doesn't matter - it's a given. And with that given,
> using Linux simply doesn't make sense, since it's slow.
Yes, you are *RIGHT* on this, I Only wonder why Linux is so much slower
than BSD. Thttpd is fast, no doubt, but compared to the massive use of
apache
it is quit not easy to configure (Ive tried to manage CGI ).
I hope the multithreaded apache (2.0) will change some things in this
strange world.
Greetings
Rob.
A single connection filling the pipe is, I would suggest,
the bare minimum. What you are concerned with on the
vast majority of web servers is how it deals with large
numbers of connections (e.g., are select and accept fast)
and for multi-process web servers (e.g., not thttpd) how
well does switching be between processes work.
As a thought experiment I did some work tweaking thttpd
and I could handle a query from start to end in something
like a half dozen syscalls (with keep-alive) and about
1/10,000 of a second (on a DEC-aka-Compaq 500au).
John
--
John Hascall, Software Engr. Shut up, be happy. The conveniences you
ISU Computation Center demanded are now mandatory. -Jello Biafra
mailto:jo...@iastate.edu
http://www.cc.iastate.edu/staff/systems/john/index.html <=- the usual crud
It says that these tests are being run with 16MB of RAM (the report is about
embedded systems). One guess as to why FreeBSD is showing up as being faster
is that it had a smaller kernel footprint than the Linux kernel being used.
These tests don't say anything about the behavior of Linux/FreeBSD on a
system without memory constraints.
--
Jon Smirl
jons...@mediaone.net
Miquel van Smoorenburg <miq...@cistron.nl> wrote in message
news:7e9qjt$svs$1...@Q.cistron.nl...
> In article <7e7v04$iub$1...@shell3.ba.best.com>,
> Jef Poskanzer <j...@acme.com> wrote:
> >You could only use half the 100Mpbs net then? With how many MHz?
> >I find that a mere 200MHz machine can fully saturate a 100MHz net,
> >as long as it's running FreeBSD.
>
> Getting linux-2.2.0.tar.bz2 from a Pentium 166 running an ancient
> Linux 2.0.34 kernel I get the following rates (file downloaded
> a couple of times to make sure it was in the buffer cache):
>
> 10592549 bytes received in 0.96 secs (10763.2 kB/s)
> ....
> I wouldn't call that bad performance.
>
> Mike.
> --
Apache can be configured to handle a request in under one syscall on the
average. See Dean Gaudet's performance tuning docs. You give up some
things of course, but if you really need that kind of performance it can
be done. Most people don't though and the extra functionality and
convenience that Apache provides is what makes it popular. It's like
going grocery shopping in a formula-1 car. Not very practical. You can
get back and forth quickly, but nobody can come with you and there is no
place to put the groceries. Your trusty station wagon gets the job done
nicely though.
-Rasmus
Huh? At a minimum, it seems to me you've got to do one read (to get the
request from the network socket) and one write (to send the results
back). How can you get it down to any less than that?
--
Roy Smith <r...@popmail.med.nyu.edu>
New York University School of Medicine
A reasonable objection. When I post my own results in a few weeks,
from a system with 1GB of RAM, we can talk again. :-)
---
Jef
Jef Poskanzer j...@acme.com http://www.acme.com/jef/
"And for you, a puppy!" "Ohhhh!"
Not really, a pipelined server with good buffering can get well under 1
system call per operation. But, I did mis-represent that a bit. You
can't do a useful Apache server in under one syscall per request. But
you can definitely get it down into the teens. See
http://www.arctic.org/~dgaudet/apache/perf where Dean presents an Apache
config with 19 syscalls per request, and you can get that a bit lower
still.
-Rasmus
Since your server is optimized for speed as opposed to added
functionality, it would be useful if you could follow the tips from
http://www.arctic.org/~dgaudet/apache/perf and configure Apache for
performance as well to compare them on equal terms.
-Rasmus
While you are in the process, would you mind also testing with a
squid in accel mode talking to apache on the loopback address on
the same host? This combination (or with squid on a different box)
gives you the best of both worlds: a non-forking lightweight single
process handling the frequent static requests out of cache RAM and
the full blown apache backend for flexibility. It also helps with
memory usage with mod_perl or large CGI programs by accepting the
output instantly and buffering it for slow clients so you end up
with fewer httpd processes running (but you won't see that in
testing unless the output is large and the test clients are on slow
links).
Les Mikesell
l...@mcs.com
At the very least you need to:
* know that something has happened [syscall #1 select]
(connection keep-alive saves a accept and another select here),
(if you are busy, you get to split your select over multiple
requests, though)
* find the time [#4 gettimeofday] (also amortized over
multiple requests)
* read the request, I used 2 syscalls here,
first I MSG_PEEK'ed at the data [#2 recv]
and the read the correct amount [#3 recv] normally
This way I didn't have trouble with reading `too-far' in the
case of a method=post request AND avoid a copy process
for CGIs [save 1 syscall here if you don't care about this]
* get the data somehow (in my case I added a file cache,
so that normally I could just check that the data wasn't
state [#5 stat] which saves an open and a read
If was was willing to put up with some 'small enough'
amount of staleness one could skip the stat if you'd
done one 'recently enough'
* write the response you can do it all at once [#6 writev]
and use non-blocking I/O to save a select,
* typically you want to log the transaction,
you can buffer a number of these before writing
them out to reduce the avg syscalls/request
So you could get the job done, absolute best case good luck
in 2+some_small_fraction syscalls:
1/N select (N fds ready)
1/N gettimeofday
1 recv (I used 2) to read the request
0 stat/open/read/close [file cache with some staleness allowed]
1 writev to write the response
1/M writev to do the log [M-buffering of log records]
Well, actually...
My most recent tests included Zeus and a not-quite-released commercial
server called Afterburner. Which I wrote. And which came out as
substantially faster than Zeus. This new series of tests I'm setting
up for is to see how they do on other OSs such as Linux.
---
Jef
Jef Poskanzer j...@acme.com http://www.acme.com/jef/
"Back off, man - I'm a scientist!"