On Fri, 14 May 2004, Tariq Rashid wrote: > > 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
Do you also do authorization from an ldap server? Can you post the authorize section? I am quite interested to see how the ldap module performs under load. Also posting the relevant rlm_ldap configuration would be quite helpful. Setting the ldap_connections_number to a correct value can be really important for rlm_ldap to work properly under load in the authorize section. Though i don't think the above behaviour can be attributed to the ldap module. > 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 > -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
