On Tue, Feb 14, 2012 at 7:57 PM, Simon Earthrowl <searthrowl@eseye.com> wrote:
Hardware: based on ESX host: 4 core 2.1GHz processor (have 24 cores to play with) 8GB Memory (have more as needed)
err ... that's not really much these days.
Limitations so far: 4 million dial-in potential users (16 million gets a bit slow - so looking for other improvements)
It's way overkill for FR with files backend. But once you include any kind of db or external backend (e.g. mysql, perl, whatever) then those system can quickly becomes the bottleneck. In the case of mysql, the bottleneck is usually disk IOPS.
In bound transaction rate (sustained mix of 1:1.5 of radius authentication:Radius accounting) 2048
2048 per what? seconds?
Response time (so far and improving) < 500mS (current gains are from reworking MySQL data tables, structures, and indexes)
That'd still mean you have a bottleneck somewhere. IIRC on a simple FR-mysql setup, I got several thousand auth+acct/sec, and that's with a pretty low max thread count (the 200-something I mentioned earlier. It's low compared to yours).
CPU utilisation is still low (as reported by VSphere) ~15% ie MySQL is running well, and so is FR. Packet loss increases to 10% 2.5K transactions/sec.
is this during your load test? If yes, then there's no reason to use 2048 threads. Really. Just lower them.
I've wanted to limit the number of threads, as if the activeMQ server fails, I don't want radius to fail (users shouldn't be penalised because of poor systems management/setup). It's all a bit too open ended for me to feel comfortable with this as a solution as it stands.
It's kinda complicated. Short version is if you use your external system only for acct, then using something similar to sites-available/buffered-sql should do the trick (i.e. log to detail file first, process later). But if you also need it for auth, then it gets compicated. Possible (especially if you only consider the case when the external system is dead), but complicated (especially if you consider the case when the external system simply becomes too slow)
My feeling is that I've yet to unleash the real power of FR; but it's far
It's pretty flexible. The hardest part is defining your policies. For example: how would you want FR to detect if your external system fails? How long must it wait?
from obvious to me, as to how to improve MySQL performance with FR. Reading others: dumping MySQL (albeit in a MySQL configuration -> local file + reload) way seems the next step.
mysql can perform just fine on super-busy implementation, IF you have the skills of a competent dba (or have someone with that skill helping you). -- Fajar