i wonder if any of the developers or other users may shed some light on this ...
as i mentioned recently i'm benchmakring and characterising freeradius and radiator - primarily for capacity planning, and being aware of "unusual" behaviour. i've written some code which send radius requests to a sever (auth|acct) and does so an an increasing rate, with the rate going up in steps. that is, the request rate increases in steps. the testing client is threaded to ensure that a slow responce doesn't throw off the client and maintains the request rate. (i know people argue about the benefit of threading on single-cpu systems, but it works for me, i am able to load radiator much more with increasing numbers of client threads). with radiator, the plots of responce time against wall-clock time or request rate follows a common and understandable form - roughly constant for low rates, then climbs to a plateau, probably as the input queue fills up. i've done quiote thorough testing with radiator (eg. remove hooks to te see effect of user supplied hooks, yusing multiple hosts, affect of proxy latency, etc etc). now I'm looking at radius 0.9.3. the inital work shows plots which are not intuitive. simply, they are ZIG-ZAG! that is, for very low request rates, the reponse time is roughly constant but then the responce time will occasionally jump (not climb) to a very high value (eg 5 secs) and the subsequent queries then take a long time, bit with progressively smaller times... as if the server is recovering from the jump... puzzling is that there is no "climb" - there jumps are discontinuities. more puzzling is that subsequent queries should be affected by this (i'm using multiple client hosts, and still see the affects to it is not a client phenomenon). my initial impressions are that - although freeradius is quicker than radiator, it is more "brittle" - the responce graohs are more erratic with much more single "long time responses" even at low request rates... whereas the radiator is much smoother and predictable. this is not a troll, i'm genuinely interested in why this may be and how we can fix it? the configuration i'm using is simply the supplied radiusd.conf, with sections commented out so that authentication occurs from an LDAP server. i have also changed the cleanup-delay to 0 - to ensure that there is no caching of the same request-responce in the server, although the same behaviour is observed with the default 5secs. from a service provision point of view, there is an argument for a more predictable smoother server, because if its too slow, you can throw better hardware at it, and still keep the reassuringly smooth characteristics. for your interest: the base (at low requests rates, ie no stress) response rate of radiator is 0.075 seconds, compared with 0.0007s (with some ghosing at 0.01), on the same hardware. tariq - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
