Alan Cox writes: > > 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.
I'm fairly sure it gave me a significant performance improvement when I was testing back-to-back gig ethernet (jumbo and non-jumbo frame) and connection via a Cisco xx08 (whatever their 8-port Gig-E switch is/was; no jumbo frames) between a couple of PCs earlier last yearish. That was for kernels around and including the one where Chris' fancy Unix domain socket fd passing in vsftpd crashed the kernel though :-). Perhaps more recent kernels behave differently--I haven't tried benchmarking fast network stuff since then but I didn't think the basic "softnet" stuff had changed much since then (modulo drivers)? > As a general theme [...] > 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. I've been trying to preach viewing "dribbling TCP data to modems" as "control unit offload work" to S/390-system guys for a couple of years now. --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
