Page 1 of 1

How to size the server

PostPosted: Tue Jan 15, 2013 11:37 pm
by HussainAkbar
I have been asked to provide the configuration of a server that can support 120 SIP channels. There will be no switching, no operators. It would have one (or more) SIP trunks. It would run ViciDial to call out and play a standard recording only (let's say of 1 minute duration).

From my own knowledge plus a little googling, I see that there is no standard sizing calculator per se as the hardware depends on other factors. However, I do need to provide something concrete to the client.

As an example, if a few of you who have no PSTN lines, only SIP, can give me a ball park figure as to which processor and how much RAM you have and (roughly) how many simultaneous connections your server is handling, perhaps I can show that to the client.

Re: How to size the server

PostPosted: Wed Jan 16, 2013 1:34 pm
by williamconley
Our Core2Quad systems (each at 2.3Ghz+ with 2G RAM standard) all easily handle 200 SIP channels under those circumstances. I do not recommend going below that (as the cost different is minimal).

Re: How to size the server

PostPosted: Wed Jan 16, 2013 11:38 pm
by HussainAkbar
William

Thanks for the answer.

Is there any way that I can put numbers in? e.g. for 200 SIP, each session takes xxx RAM, etc? i.e. Make it more official sounding?

Re: How to size the server

PostPosted: Thu Jan 17, 2013 6:36 pm
by williamconley
There are many opinions on that. But remember that your experience will be different. We like to allot 100K per user for bandwidth if using ulaw. For CPU, however, calculations hit too many variables (bus speed? HD speed for both data transfer and I/O wait time? memory speed?). But you have no users. Just calls. It's very difficult to calculate. We've had these servers stable up to 350 channels for some clients and only 250 for others.

It also depends a lot on available bandwidth and your carrier's capability to connect calls per second (5 per second? 100 per second?).

And there is the unkown of AMD and how many calls actually answer vs are made (answered calls take more resources than dialed calls ... and you don't know how many will answer vs how many you dialed until it happens).

All these things make a difference. Try it and find out :)