Re: [Serusers] ser scalability

Sabatella, Michael wrote: Hard to say, really, as it depends more on what you do during call processing then anything else. If you use the exec module for every call, it will probably be rather limited. The normal game with just forwarding call requests scales extremely well. It is and you are not. By default SER is using a rather small amount of memory, somewhere in the megabytes. Putting more memory into the box would not help. There is a point where the defaults are too small and SER won't start, because it wants to slurp the entire location table into memory but doesn't have enough of it. I don't quite remember when that happens or the name of the parameter in config.h that you have to change and recompile. There is another point later on where SER will not have enough shared memory anymore, but you can fix that easily via the -m option. I have seen a single server of whatever was decent five years ago running the complete service for 150,000 customers. And that was far from the end of the line, it just got scary at that point to have only one server. I would advice against using virtual machines. We only have been using vmware and probably a bit old version at that, but high IO was a bit of a problem. By and large, SER is only doing IO, so there is trouble ahead. With 300 users, there will be none, but with growing numbers you may see mysterious crashes and hangups which are best countered by buying a real server. Doesn't need to be anything fancy, really. SER gives you a bunch of statistics with the serctl thing. Plotting these and keeping an eye on them seems a good idea. Among others, you have shared memory usage, which shouldn't be too high. You need a little script that aggregates the accounting data into calls. Bit of Perl or Python or just plain SQL even. But be aware that usual telco measures don't necessarly apply. Number of parallel calls is stupid from a SER perspective as it isn't call stateful. It becomes interesting again if you do nathelping with rtpproxy, as there are limits in what rtpproxy can do, and of course for bragging. Otherwise, call setups per second are probably interesting. In practice, though, you will have between 10 and as much as 50 times more registrations than call setups (depending on how eager callers your customers are). So this is what you should look out for. Depending on your setup, each registration may also include a database write which is much more expensive then a mere select. HTH and regards, Martin