[Date Prev][Date Next] [Thread Prev][Thread Next]
FW: Red Hat, Speed, and a Web server
- From: Jesse Noller <jnoller allaire com>
- To: "'tux-list redhat com'" <tux-list redhat com>
- Subject: FW: Red Hat, Speed, and a Web server
- Date: Tue, 20 Mar 2001 16:10:29 -0500
Below you will find a reply to an email I sent to the guinness-list
earlier, below that, you'll find the original email. Could any of you shed
any light on the questions I pose? Any help is appreciated.
From: Jesse Noller [mailto:email@example.com]
Sent: Tuesday, March 20, 2001 3:25 PM
Subject: RE: Red Hat, Speed, and a Web server
Well, it would seem that you should start with Ingo's TUX webserver as
a base, and work on TUX cgi modules and integration with Apache.
RedHat is devoting significant resources to TUX in the form of Ingo's
and David S. Miller's development time, as well as that of several
others who are working on documentation and configuration. Witness the
generic zero-copy infrastructure that David has prepared for inclusion
Hmm. My problem is that I am not clear on userland modules for Tux.
Basically, my SPECIFIC task is to builf the fastest base box I can, and then
install an APP server my employer makes to see what sort of speeds I can
Basically, the app server runs off of an Apache DSO module. Now, if
it was easy to convert and or tie DSO modules into tux so that it can hand
off page translation requests, then I could see this as viable. Now,
seperate of my employer-given task, I will be fully exploring Tux as a
viable STATIC content server.
TUX is under very active development (sometimes multiple releases/day).
The releases are a set of patches on top of Alan's -ac series.
Yep, I am on the tux-list
Go to the Red Hat mailling lists page, read the archives, and subscribe.
If Ingo can make Linux go faster, he will -- he's responsible for many
of the scalability improvements in 2.4. Just understanding how TUX
gets its performance (event model, page cache, irq affinity, zero-copy,
etc.) is a good starting point.
Thanks, makes sense!
An actively maintained website with a knowledge base and a bunch of
optimized RPM's for server tasks would be a blessing.
Yes, I thourghly planned on making a site dedicated to this. I just don't
know how fast I can put it up, or if I can maintain it on my own. I had
planned on making the site something along the lines of
http://speed.rootmonkey.com (I won the domain, don't bother, there isn't
Well, I have sent this message out in the past and not received any
real good feedback, so, I thought I'd try it again. Basically, I have a
task. I have to build the fastest Linux web server I humanly can.
Now, I am wondering, if there is any interest in a project like
this? I mean, we have numerous projects out there, like the Citi Project
(http://www.citi.umich.edu/projects/citi-netscape/) However, not only is
there information outdated, so are the kernel tweaks.
What I would like to do is this: Examine, from the ground up, how to
make the different parts of a Red Hat box move as fast as possible. Starting
with the kernel, and the tcp/ip stack, and ending with Apache.
My particular task is this:
Start with a vanilla Red Hat 7.0/7.1 box. Load ANY kernel you want,
trim the entire system to be as fast as it can be, this means Disk and Stack
I/O, tweaking nic card drivers, and ending up finally, taking a stock
version of Apache 1.3.x and 'tweaking' it.
My hopes, from this project is to not only have a living, recent
document/white paper detailing out the steps, but also having a website
dedicated to patches, readmes, etc.
To my knowledge, the only official vendors or groups who have any
slight interest in this are the Citi group, and the SGI groups, although,
SGI recently dropped their apache work, and most of their kernel stuff is
for 64 bit only.
Also, to this date, I have not found a Linux vendor capable and
willing to dedicate time and resources to such a project, although such a
project benefits everyone. We don't need anymore 'mindcraft' results, and
with the market downturn, everyone is looking for the most bang for their
So far, these are my facts/tweaks to date:
1. Install 2.4.2 kernel, check internal kernel documentation for any
2. Load IPtables so that it block all traffic with Reject packets
except for port 80, that way, no other requests can come into the stack.
3. Possibly load Ext3, see how much of a speed gain can be had from
altering the disk system itself.
4. Check hardware duplexing on Ext2 FS
5. Mount file system no ATIME
6. Load up on RAM, make sure almost nothing is swapping out, and
everything is going into Ramspace
7. Remove ALL unneeded kernel modules, and system services
8. Download Apache source, remove ALL unneeded modules, in fact,
remove all compiled-in modules, and go straight DSO, that way, apache will
be handling less in the translation
9. Apply SGI patches to apache 1.3.x
10. edit source setting certain value inside of apache to be the
maximum allowed limit.
Next, here are the links I have been able to find on the subject:
And so, in the end, if anyone is interested in helping me, or
donating information/code/patches, please, let me know. Especially, if you
have homebrewed tweak information.
Thanks for your time. I now return you to your regularly scheduled
Linux Systems Lead
[Date Prev][Date Next] [Thread Prev][Thread Next]