Load test freepbx for Calls

hi Everyone,

Can anyone guide me how to stress load test my Freepbx for Call Volume and other parameters.

Please suggest me how can I Stress load test my pbx.

I have no guide, but I’ll say this: Blindly trying to push something will always cause it to fail. Always have targets you want to achieve and always have scenarios.

1 Like

I want to setup it for IVRs and will be receiving incoming calls.

S, for that I have to share projections.

Any tool I can use. paid or opensource ?

Any stress test is going to be for calls only. As in endpoint to endpoint, not endpoint to PBX that will do a bunch of extra things like playback recordings, launch scripts, await input, etc.

Without knowing what your full expectations and use case will be we cant offer input on what you will need. Stress tests imply a lot of calls, like hundreds a second. Unless you are planning for usage on that level I dont think you need to worry too much unless you are running some low end system.

1 Like

A simple search on Google for “sip load tester” will yield numerous paid products. I see several on the first page of results.

Free/open source, you would build it yourself using tools like sipp or another asterisk server scripted to do call origination.

Seconded on sipp, but I will tell you when we tested vs. real life, it was very different. A lot of it had to do with what was anchored to the box and other services that might be at play.

Starting here: Sangoma Documentation
Can also be a good barometer.

(I always believe everything the car dealer tells me also :wink: )

One thing I will point out is since FreePBX runs on x86/amd64 hardware, there is ALWAYS an answer for when a high volume call application starts to notice problems - and that is, to buy a bigger-faster-more powerful hardware server with more ram for it. Up to the limit of the fastest hardware available, of course.

So let’s do some back-of-the-envelop calculations. Assuming uncompressed codec that’s 64kb per call, assuming 80% ethernet utilization on a 100% gig-e network before packet delays and retransmits and drops become a problem, and assuming all extensions are running calls simultaneously meaning you would need 1 trunk per extension, and assuming a cost of perhaps $15 per month USD per trunk.

That would mean your fabric could support around 12,500 simultaneous conversations, at a cost of approximately $187,500.00 USD monthly for the trunks. The difficulty though would be delivering those, I’m not sure a SIP provider exists out there that could deliver 12 thousand SIP trunks all to one site so you would have to bring it in on multiple OC3s, correct? You also would need a large office building for the 12,000 warm bodies on the ends of those extensions your payroll would be in the millions of dollars a month.

Now, could a single PBX support this on a powerful PC server? Well, yes I think it could because remember once the call is established the PBX isn’t doing anything it’s the extension communicating directly with trunk. Even sometime around 20 years ago when Walnut Creek still existed there were stories of them using a SINGLE Xeon PC running FreeBSD serving 4000 SIMULTANEOUS ftp clients, that is ALL communications terminating on ONE pc. And 2000 inserts per second into mysql on a crappy laptop running on a SSD drive is easy-peasy.

If you have your 12,000 agents limited to maybe 5 minutes per call and they are busy all 8 hours of the day well then I think it’s possible for FreePBX to handle a million calls per day, given the right network.

Is that high enough for you?

I found out the hard way that call recording, transcoding, call center blasting, voicemail, IVR, and FOP all factor into the PC’s capacity. Only real world testing will expose the limits.

1 Like

Why on earth would you have 1 trunk per DID. That is just a stupid way to configure things that adds overhead.

I also don’t think any call center that would use direct media. That completely breaks the option to record calls and monitor calls.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.