1- See also SPEED 2 3Update 2nd Nov 2001 4ftp.redhat.com ran vsftpd for the RedHat 7.2 release. vsftpd achieved 4,000 5concurrent users on a single machine with 1Gb RAM. Even with this insane user 6count, bandwidth remained totally saturated. The user count could have been 7higher, but the machine ran out of processes. 8 9-- 10Below are some quick benchmark figures vs. wu-ftpd. This is an untuned BETA 11version of vsftpd (0.0.10) 12 13The executive summary is that wu-ftpd got a thorough thrashing. The most 14telling statistic is wu-ftpd typically failing to sustain 400 users, whereas 15vsftpd copes with 1000 with room to spare. 16 17A 2.2.x kernel was used. A 2.4.x kernel should make vsftpd look even better 18relative to wu-ftpd thanks to the sendfile() boosts in 2.4.x. A 2.4.x kernel 19with zerocopy should be amazing. 20 21Many thanks to Andrew Anderson <andrew@redhat.com> 22-- 23 24Here's some benchmarks that I did on vsftpd vs. wu-ftpd. The tests were 25run with "dkftpbench -hftpserver -n500 -t600 -f/pub/dkftp/<file>". The 26attached file are the summary output with time to reach the steady-state 27condition. 28 29The interesting things I noticed are: 30 31- In the raw test results, vsftpd had a much higher peak on the x10k.dat 32transfer run than wu-ftpd did. Wu-ftpd peaked at ~150 connections and 33bled down to ~130 connections, while vsftpd peaked at ~400 connections and 34bled down to ~160 connections. I tend to believe the peaks more than the 35final steady-state that dkftpbench reports, though. 36 37- For the other tests, our wu-ftpd setup was limited to 400 connections, 38but in about half of the x100k/x1000k runs could not even sustain 400 39connections, while vsftpd handled 500 easily on those runs. 40 41- During the peak runs at x10k, the machine load with vsftpd looked like 42this (I don't have this data still for the wu-ftpd runs): 43 4401:01:00 AM all 4.92 0.00 21.23 73.85 4503:31:00 AM all 4.89 0.00 19.53 75.58 4605:11:00 AM all 4.19 0.00 16.89 78.92 4707:01:00 AM all 5.61 0.00 22.47 71.92 48 49The steady-state loads were more in the 3-5% user, 10-15% system. For the 50x100/x1000 loads with vsftpd, the system load looked like this: 51 52x100k.dat: 5309:01:00 AM all 2.27 0.00 9.79 87.94 54 55x1000k.dat: 5611:01:00 AM all 0.42 0.00 5.75 93.83 57 58Not bad -- 500 concurrent users for ~7% system load. 59 60- Just for kicks I ran the x1000k test with 1000 users. At peak load: 61 62X1000k.dat with 1000 users: 6304:41:00 PM all 1.23 0.00 46.59 52.18 64 65Based on what I'm seeing, it looks like if a server had enough bandwidth, 66it could indeed sustain ~2000 users with the current 2 process model 67that's implemented in vsftpd. I did notice that dkftpbench slowed down 68the connection rate after 800 connections. I'm not sure if that was a 69dkftpbench issue, or if I ran into something other limit. 70 71