Sabatella, Michael wrote:
1. What is the scalability of ser processing calls?
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.
2. Are there any limits on the number of users
that can be
registered at one time. Is the registration memory based and am I
severely limited with 4GB of memory?
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.
3. Is there anyone that has 1000s of
registration to the proxy
and if so I would like to hear how you are scaling it. What type of
server are you using?
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.
4. What are some good metrics to look at on the
sip proxy to
gauge its performance?
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.
5. Is there a way to capture calls per minute?
Is anyone doing
this? I have call accounting set up.
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