[Devel] acc diff

[Dan Pascu]

On Tuesday 03 October 2006 17:34, Juha Heinanen wrote:
> Dan Pascu writes:
>  > It doesn't work even now, but I have a simpler way around it
>  > currently. I let it define User-Name as it does and if I need
>  > something else I define an extra attribute and set an avp for it.
>  > Then I let freeradius pick this extra attribute if defined else pick
>  > the standard User-Name as freeradius has such a fallback mechanism
>  > to the first defined variable in a list.
>
> so your proxy wastes cpu cycles and calculates the default UserName
> also when you don't need it.  this is not acceptable to me.

No offense but this is hilarious. You really believe that if you move the 
logic to compute the username from the fast internal C code into the 
interpretted script where in addition you also perform AVP manipulation, 
you think that this will save you CPU cycles? Excuse me while a giggle.
Even the simplest version where you use my proposed $un directly and do no 
AVP manipulation at all, will be slower than before given it has to be 
taken via the script as an extra radius attribute.

I agree that this change will give more flexibility, but more speed?!? 
Only if people stay with the minimal set, which I have a hard time to 
believe they will do, given that it makes accounting records useless.

This obsession with performance is starting to really piss me off. Because 
of it, people fail to see the bigger picture and are willing to sacrifice 
anything for the sake of the Almighty Performance.

I have serious doubts that anyone has done any serious profiling on 
openser to see where are the bottlenecks. Until that is done is useless 
to talk about optimizations, as it is useless to optimize the things that 
take maybe less than 3% of the overall processing time until optimizing 
the things that take 80% of the time. I also haven't seen any performance 
seeker yet to provide a profiling report that shows how a change has 
improved performance and by how much.
Performance optimizing is NOT a straight-forward process. Often things 
that look straight-forward and indicate a sure performance gain are found 
to actually degrade performance when applied because of unaccounted side 
effects.

And if I have to make a guess even without any profiling report, I'd say 
that currently openser's bottlenecks are the database access and DNS 
lookups. Even if openser can process thousands of requests per second 
with a simple loop that does no database access and no DNS lookups, with 
database access and DNS lookup added to the scheme it will fall to a 
merely 300-400 requests per second at best. Considering that you have to 
make 5-10 database requests per each transaction during the initial call 
setup, and usually at least 1 ENUM lookup per transaction, you see where 
this is going.

I have benchmarks with a MySQL database and it can drive approximately 
2000 queries per second. Now if you need 5 database accesses to make a 
call setup, you are limited to 400 requests per second by the database 
only. Forget the 10 CPU cycles that you gain by optimizing some corner 
situation. It won't improve anything until the more important bottlenecks 
will be dealt with and even then it may not gain anything significant to 
be worth considering.

And to make a conclusion to this rant, I do agree this change can be a 
good thing if done properly. Not because it improves performance (I doubt 
it will really improve anything), but because it offers more flexibility 
and if done properly will allow for easy transition and backward 
compatibility without making the configuration more complex for those 
that do not need the extra flexibility.

-- 
Dan