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 _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
