performance, stability, benchmarks - some puzzles?
i've started on somebenchamreking of radius servers - after some initial trouble withf orking and then threads. despite the fact that the received wisdom is that threading does not allow you to write faster clients that hit a server harder (clients, with each thread doing the request and timing the responce) - there does in fact appear to be some performance gain from threads on single-cpu clients - probably because other threads can "get in" when between other threads in less time than it takes to create single sequential threads. if anyone can throw some light on this i'd be grateful. the server is currently single-threaded (radiator, freeradius will also be tested next). anyway - the puzzle i'm facing is that i'm apparently seeing odd results? i'm seeing a typical graph of response time against request rate. as the request rate goes from 1/sec to higher rates... the responce time is initially very flat at 0.075secs... then at a specific rate it climbs almost linearly to a peak ... and then plateus at this max. the max may be due to client or server limits... i haven't investigated yet. however... it appears that different client machine speeds give different points at which the responce time starts to climb from its initial rapid baseline. you may suggest that the clients are reching their thread scheduling or network limits at different request rates. but the faster machine (dual 3Ghz Zeon) seem to reach this poiont before the slower ones (amd 800Mhz single cpu)? how can this be? could it be that the faster machine actually manage to switch threads faster and so do in fact hit the radius server harder? thoughts appreciated - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: performance, stability, benchmarks
Htin, good point! - the start up time is certainly orthogonal to the two items i listed. in terms of overall customer service - it certainly does affect customer service if a configuration change and server restarts requires 5 or 10 minutes (exaggerating the figures here). even the time to become responsive after a "kill -HUP" may be more appropriate as this should be more the norm within service providor environments. i will add your item to my list of things to compare... thank you! tariq -Original Message- From: Htin Hlaing [mailto:[EMAIL PROTECTED] Sent: 30 March 2004 17:31 To: [EMAIL PROTECTED] Subject: RE: performance, stability, benchmarks Tariq, I am also very interested in those two as well, especially with EAP types. I am not sure if this is relevent but I am also interested in start up time? What are the factors which can have impact on the start up initialization time of a FreeRadius server? Thanks, Htin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tariq Rashid Sent: Tuesday, March 30, 2004 8:21 AM To: '[EMAIL PROTECTED]' Subject: RE: performance, stability, benchmarks let me rephrase a little of my last post. i belive the two items indicative of service from the perspective of a service provider are: * response time - slow respnce time leads to customer complaints * stability - a fast system which crashes often is also no good are there any other indicators that should be in this list? tariq - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: performance, stability, benchmarks
Tariq, I am also very interested in those two as well, especially with EAP types. I am not sure if this is relevent but I am also interested in start up time? What are the factors which can have impact on the start up initialization time of a FreeRadius server? Thanks, Htin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tariq Rashid Sent: Tuesday, March 30, 2004 8:21 AM To: '[EMAIL PROTECTED]' Subject: RE: performance, stability, benchmarks let me rephrase a little of my last post. i belive the two items indicative of service from the perspective of a service provider are: * response time - slow respnce time leads to customer complaints * stability - a fast system which crashes often is also no good are there any other indicators that should be in this list? tariq - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: performance, stability, benchmarks
let me rephrase a little of my last post. i belive the two items indicative of service from the perspective of a service provider are: * response time - slow respnce time leads to customer complaints * stability - a fast system which crashes often is also no good are there any other indicators that should be in this list? tariq - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
performance, stability, benchmarks
to continue the theread on radius performance and stability characteristics .. i'm trying to identify a list of items/metrics/indicators to measure. for example: * radius response time with constant radius query rate * radius response time with increasing radius query rate * radius server memory consumption with zero radius query rate * radius server memory consumption with constant radius query rate * radius server memory consumption with increasing radius query rate i wonder if anyone can identify other useful items that are insightful from the perspective of mant of use who rely on radius/freeradius/radiator for service provision. not that there are variables of the above test which are "environmental variables" which can usefully be studied ... such as: 1. backeends... eg sql, users file, ldap 2. hysteresis (ie rate up and down) - leaking of resources 3. different servers 4. linux, 2.4, 2.6, freebsd 4.9, 5.2.1 ... 5. perl versions, 5, 6, compiled parrot? 6. os parameters on used system freebsd 4.9 ... egh mbufs, pre-alloc? noatime on FS whilst logging, etc etc etc 7. acct on/off 8. multiple instances of server .. you can suggest more ... but these are side issues. my main question is what more can i ass to the first list of server "health" indicators. radius response time is certainly an indicator of "health". the memory consumption is too... as its pretty orthogonal to the responce time (you can maintain a very good response time, but use up all your memory... which is not very healthy). you might suggest I/O but this is secondary i believe. for constant response and memory consumption, it shouldn't matter if I/O is high or low? should it? do enlighten me... tariq - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
