> > The same question for 2.4.7.
You should not be using a kernel as old as 2.4.7 on a network really. There
were various security problems fixed that are pretty bad in 2.4.7.
> Start with
> # echo 262144 > /proc/sys/net/core/wmem_max
> # echo 262144 > /proc/sys/net/core/rmem_max
> to raise the maximum read/write buffer size internally from 64K to 256K.
That's only really going to help you if the latency of the link is very
bad (or of the app - eg if your I/O subsystem is slow and bursty). It also
requires large window support both end - which at least nowdays you can
assume a lot. Changing rmem/wmem is great for satellite links but not much
else.
> know what you're doing). Another big improvement is possible if your
> ftpd supports using sendfile() which allows for zerocopy (well,
> (n-1)-copy since you need specific combinations of networking hardware
> and drivers to get true zero-copy). One ftp daemon which supports
> sendfile is vsftpd ("Very Secure ftpd") written by Chris Evans. I'm not
> sure if proftpd supports it out of the box: it didn't used to but I've
> a feeling modern versions might. (Needless to say, don't use wuftpd...).
proftpd can do it. vsftpd is much more scalable than proftpd in my own
testing. It is also supported by thttpd which is a superb open source static
content http server (www.acme.com). Its cgi behaviour is generally
comparable to apache. thttpd is used for things like the userfriendly image
serving because apache simply won't scale that way.
As a general theme
- sendfile helps a lot if you have poor memory bandwidth
or need to shift a lot of larger things.
- increased buffer sizes help with latency (eg satellite
links).
- careful choice of event models (asynchronous I/O, signal
based I/O) improve scalability of largely parallel low
volume processing (classics being ircd and low bandwidth
http). Ironically its harder to make a web server scale to
2000 parallel modem users than to shift five times the
traffic to high speed users.
Things to beware of
- Select on thousands of file handles
- Large numbers of threads
- Doing lots of small rather than large I/O's
- TCP behaviour when writing lots of small things. Notably
TCP will delay partial packets to reduce the packet count
and up efficiency. This can be a problem for a certain class
of application (see man setsockopt)
- Huge amounts of context switching
- Capture effect (high bandwidth users tend to push out low
bandwidth users, so rate limiting can actually improve the
overall experience for a web/ftp site)
beyond that you can cheat 8) using kernel based accelerators such as tux
and tuxftp which provide extremely efficient kernel based assists to the
business of web and ftp serving and get you saturating gigabit links on
x86.
Alan
