Simon Earthrowl wrote:
Limitations so far: 4 million dial-in potential users (16 million gets a bit slow - so looking for other improvements)
You need to design your solution VERY carefully. Scaling to 4M users isn't the same as 1K or 100K users.
In bound transaction rate (sustained mix of 1:1.5 of radius authentication:Radius accounting) 2048 Response time (so far and improving) < 500mS (current gains are from reworking MySQL data tables, structures, and indexes)
Response times of 500ms is RIDICULOUSLY bad. You have a catastrophic design decision somewhere. Find it, fix it.
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.
My smart phone can handle 2.5K RADIUS packets/s. It's the REST of the system that needs fixing.
I am looking to use activeMQ to relieve some of the 3ggp (3ggp-Location etc.), add enrichment; and then ultimately manage quotas with overuse getting PoD.
You're again talking about a solution. Is using activeMQ a *requirement*? Or is it a potential solution?
I'll be testing a local activeMQ server later today, with a view to either give it up as a bad idea, or to find some other way (postath database processing?).
To do... what? Find out what you need to do per request. Make it as cheap as possible. Do as little work as possible per request. Post-process as much as possible.
My feeling is that I've yet to unleash the real power of FR; but it's far 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.
For 4M users? Not a good idea. I've built multiple systems with many-millions of users. It requires a bit of care, but it's possible. Alan DeKok.