doc/performance-testing

   1
   2 Radius Test Procedures
   3
   4 0.  INTRODUCTION
   5
   6 This document describes how to test your radius server authentication
   7 using random usernames and passwords with the 'radclient' program.
   8
   9 1.  WHY TEST
  10
  11 Many people want to see the difference in efficiency behind the various
  12 authentication methods, compilation methods, etc of their radius server.
  13 Before now, this was difficult to do efficiently across a large number
  14 of users.  However, with this document, you'll be able to test your
  15 radius server and determine the best options to use for your system.
  16
  17 2.  GETTING STARTED
  18
  19 First thing we have to do is generate a large number of users.  You'll
  20 want to do this even if you have a large passwd file you want to use
  21 from your system, because the create user script sets up other files
  22 you need for testing.  So head to the scripts/ directory, and do this:
  23
  24 Make a tmp dir
  25 # mkdir tmp
  26 # cp create-users.pl tmp
  27 # cd tmp
  28
  29 Run the script to create 10,000 (or however many you want) random users
  30 and passwords
  31 # ./create-users.pl 10000
  32
  33 Output from the script will include several files:
  34         passwd : A standard passwd file you can append to /etc/passwd
  35         shadow : A standard shadow file you can append to /etc/shadow
  36 passwd.nocrypt : A file with *unencrypted* users & passes in form "user:pass"
  37    radius.test : File you'll use as input for radclient
  38   radius.users : A standard radius 'users' file
  39
  40 So, equipped with lots of users and passwords, there's several methods of
  41 authentication you can test:
  42
  43   o  System users (Auth-Type:=System)
  44   o  Local users (Auth-Type:=Local)
  45   o  Cached system (passwd) users
  46   o  Others
  47
  48 NOTE:  Before moving on, you will probably want to add '/dev/null' to
  49 /etc/shells *temporarily* so that default system authentication will
  50 work.  REMEMBER TO TAKE IT OUT!
  51
  52 3.  TEST PROCEDURES
  53
  54     A.  System (/etc/passwd) users testing
  55
  56         1.  Append the 'passwd' file from create-users.pl onto your
  57             system passwd file:
  58
  59             # cat ./passwd >> /etc/passwd
  60
  61         2.  If you have shadow, append the shadow file onto /etc/shadow
  62
  63             # cat ./shadow >> /etc/shadow
  64
  65         3.  Make sure you have a DEFAULT user similar to the following
  66             in your radius 'users' file:
  67
  68             DEFAULT Auth-Type:=System
  69                     Reply-Message = "Success!"
  70
  71         4.  Start radiusd
  72
  73             # /usr/local/sbin/radiusd
  74
  75         5.  Run radclient with 'radius.test' as the input file.
  76
  77             NOTE:  First you need to setup a secret for your local
  78             machine in the 'clients' file and use that secret below
  79
  80             # time /usr/local/bin/radclient -q -s -f radius.test \
  81                <yourhostname> auth <secret>
  82
  83                                 NOTE:  The above is to be put all on one line.
  84
  85             NOTE:  Some systems do not have the 'time' command,
  86             so you may need to break out the stopwatch instead :)
  87
  88             Take note of the output of radclient.  If there were lots of
  89             failures, something is wrong.  All authentications should
  90             succeed.
  91
  92         6.  Take note of the output from the above 'time' command.
  93             The output format should be something similar to the
  94             following (on linux, this for example only!):
  95
  96             1.72user 0.53system 5:11.34elapsed 0%CPU
  97             (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs
  98             (340major+29minor)pagefaults 0swaps
  99
 100                                 This means it took 5:11 (311 seconds) to authenticate
 101             10,000 users.  Simple division tells us this is:
 102
 103             10,000 auths / 311 seconds = 32.1543 auths/second
 104
 105     B.  Local users testing
 106
 107         1.  Copy the 'radius.users' file from the script over your 'users'
 108             file.  Make sure you do NOT have a DEFAULT entry or you will
 109             invalidate this test.
 110
 111         2.  Restart radiusd (kill and restart)
 112
 113         3.  Run radclient (See A-5 above for NOTES on this):
 114
 115             # time /usr/local/bin/radclient -q -s -f radius.test \
 116                <yourhostname> auth <secret>
 117
 118         4.  Take note of the output from the above 'time' command, and
 119             divide the number of auths (10,000 in this case) with the
 120             number of seconds it took to complete.  See A6 above for
 121             more info.
 122
 123          C.  Cached system users
 124
 125         1.  Set 'cache=yes' in your radiusd.conf file
 126
 127         2.  Restart radiusd (ie, kill it and restart, not just a HUP)
 128
 129         3.  Perform the same steps outlined above for testing System users (A)
 130
 131     D.  Other methods
 132
 133         There is no reason why you can't use some of this to test modules
 134         for PAM, SQL, LDAP, etc, but that will require a little extra
 135         work on your end (ie, getting the users/passes you generated into
 136         the corresponding database).  However, by now you should have a
 137         good idea of how to test once you do that.
 138
 139         Also, play around with compile options like --with-thread,
 140         --with-thread-pool, etc.  Run radiusd with '-s' so it runs
 141         one process only, etc etc.  Play around with it.
 142
 143 4.  CAVEATS
 144
 145 The above test procedures make no allowances for users that login with
 146 incorrect usernames or passwords.  If you want a true test of performance,
 147 you should add in lots of bad usernames and passwords to the radius.test
 148 file and then re-run 'radclient' with that file as input.
 149
 150 Additionally, these tests make no reference to how the pre-authenticate,
 151 post-authenticate, and accounting methods you choose could affect server
 152 performance.  For example, checking for simultaneous use after authenti-
 153 cating the user is obviously going to slow down authenticate performance.
 154
 155 The numbers you get from this test are raw authentications/second in a
 156 perfect environment.  Do not expect this kind of result in the real world.
 157 However, having tested in this manner, you will have a good idea of which
 158 authentication methods and compilation options give you the best base to
 159 start from, which is key to an efficient server.
 160
 161 5.  RESULTS
 162
 163 I'd really rather not post results because they will vary tremendously
 164 with other system-specific configuration.  This is exactly the reason
 165 you should run tests of this nature, to find what's best for *your*
 166 system.  Good luck!
 167
 168