release/src/router/vsftpd/BENCHMARKS

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