httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Module Project Wishlist
Date Sat, 26 Aug 1995 18:34:42 GMT
   Date: Sat, 26 Aug 1995 12:13:28 -0500 (CDT)
   From: Max Levchin <delph@new.math.uiuc.edu>

   Hi, I joined the list very recently, so perhaps I am asking about/for 
   something that has already been done/discussed here. I am very interested 
   in developing some sort of an interface for adding server-side 
   parsed and executed features to Apache. What has been done on this?

Nothing yet, but Cliff Skolnick and I are both interested once we have
a release which is bug-free enough to call 1.0, and we lift the
feature freeze.  (I have a particular interest, since the module
interface was basically my design originally...).

   I am 
   trying some of these myself and would like to know if anyone else is 
   working on the same issues. Another big thing [for me] is cacheing and 
   generally optimizing the server towards as little disk access as possible.

Well, on my box, it did very little the last time I checked, but then
again, that's on a machine with *lots* of RAM, configured to use large
amounts of it as file-system block cache (as for a fileserver); there
is a pattern of roughly 0-7 I/Os per second on the (sole) disk drive,
interrupted by fairly periodic bursts of 30-40 writes, which I'm
interpreting, for lack of a better idea, as periodic syncs writing new
last-accessed dates into the inodes.

Of course, not every system is like this (not by a long shot), but
this does raise a few issues relevant to any I/O tuning effort:

*) You need to know that what you're tuning makes a difference.  That
   means at the very least, a way of generating test loads and
   measuring performance.  (I've got a program called webmonkey which
   replays the GET transactions out of a log file and reports latency,
   though it doesn't do POST or authentication; see

     ftp://ftp.ai.mit.edu/pub/users/rst/monkey.c

   for the code).  Of course, if you also have a way of telling what
   sort of I/O the program is generating, and which sorts of requests
   account for what fraction of the load, so much the better.

   (NB tuning stuff that doesn't make a difference is a classic
   rathole down which many very smart people have fallen, and which is
   worth some trouble to avoid; Jon Bentley's book on the subject,
   entitled "Writing Efficient Programs" has a wonderful anecdote on
   the subject which is too long to fit in the margin of this email).

*) You should probably avoid trying to cache stuff that the operating
   system is caching for you anyway (e.g., every Unix system that I've
   ever run across has a RAM cache for the file system, though its
   size may be variable, and may be configured too low on a lot of web
   server setups).

Probably the first thing to look at is scans for .htaccess files (most
of the .htaccess files the server looks for in a given request don't
exist, which means that searches for them never hit in the typical
namei cache); however, there, judicious use of "AllowOverride None" in
the config files can reduce the incidence of that significantly
without even touching the server code.

rst

Mime
View raw message