I have a question regarding the capacity and performance of an Asterisk 20 and FreePBX 17 system running on a cloud server or VPS, rather than on a physical server.
For Asterisk 20 and FreePBX 17 using PJSIP, what would be a reasonable amount of resources to allocate to this server?
I am planning to estimate resource requirements based on concurrent calls (CCU). For example, if a VPS with 2 vCPUs, 2 GB of RAM, and SSD (or NVMe SSD) storage, using the G.711 codec, can handle 10 concurrent calls, I could use that figure to estimate the requirements for 30–50 or 100 concurrent calls.
Basically, I want to calculate the appropriate resources to allocate for different call volumes, without overprovisioning or underprovisioning.
Has anyone tried estimating this before? I would really appreciate your thoughts and feedback.
No, he’s saying if those stats = 10 concurrent calls he can work from that and extrapolate what he needs for larger systems.
However, when asking questions like this user count is down on the list of “what will need resources”. Transcoding, recording, heavy AGI/System usage…these are some of factors that matter more for what resources you need on the system than “I have X users”.
Why are you focused on calls? Degrading can happen before the 11th call. We just discussed this in the SBC thread. Asterisk is a B2BUA only meaning everything ends up in the SIP stack and everything creates a dialog. Once you’re in the SIP stack creating and managing dialogs that adds more resources being used. The task processors could end up hitting their queue limits and start queuing requests which will result in things not processing as fast (or not at all).
A system that is doing heavy call recording or transcoding or calling on external scripts via AGI/AMI/System or even ARI calls/stasis apps with only 10 users would need more resources than a system with 50 not doing recording or transcording or even external script calls. Why? Because the former system is doing more resource intensive tasks vs the latter system.
Correct and the OP doesn’t have a reference point. They are trying to create one. So a 2 CPU/2GB RAM system may work fine for 10 users or it may not be enough for 10 users. It really depends on what the overall system expectations are. What are all the things the system is going to need to do and then you can figure out how the user count will impact that.
Basing everything off of “I got X users” is just waiting for disaster to happen because you’ve ignored all the other things that actually suck up CPU/RAM or disk space.
Thank you for your feedback. The goal is not to precisely calculate how many CPUs/RAM are required for 10, 30, or 50 calls. Rather, under specific conditions, the goal is to estimate how much resource is needed for stable operation without compromising call quality.
10 calls are just an example. As mentioned above, suppose the system runs on:
The above setup is quite simple and common. Under these exact conditions, what resources should be prepared for volume milestones of 20, 30, 50, or 100 concurrent calls?
Or more simply, are there any tools available for load testing or simulation?
I wouldn’t use a simple “X vCPUs = Y concurrent calls” formula here. The actual load can change quite a bit depending on what Asterisk is doing with those calls, especially recording, transcoding, queues, conferences, CDR/AMI activity, and the dialplan. I’d start with a small VPS and run a controlled load test while watching CPU, RAM, I/O and Asterisk task queues, then increase the resources based on the results. That seems much safer than assuming 10 calls on 2 vCPUs will scale linearly to 100. I’d also keep the same kind of capacity and call-source visibility in mind with a platform like Phonexa.
I have 35 FreePBX 16/17 instances on Vultr - most of them are 1 CPU 2G of RAM and they easily handle more than 20 simultaneous calls without breaking a sweat. I have never had a problem with any of these instances.
If I have more than 20 extensions, I move up to a 2 CPU 4G of RAM instance.
One of those 2C/4G instances is a clinic that only takes new patients on the first of the month, so their phones are always maxed out with 50 people in the Queue (holding) and 10 people being talked to at any given time.
RAM is not the limiting factor (once you have exceeded the minimum) - It’s transcoding.
Transcoding from G.711 to G.729 is fairly CPU intensive - Digium used to sell a card that did the transcoding in Hardware (I still have one but I don’t use it) because it bogged the machines down so badly.
Recording that many calls simultaneously might tax the system’s disk subsystem, so if that is a requirement, look at the Storage offered and lean into NVMe versus SSD.
Don’t go crazy - the people telling you that you need the super-beefy VPS’s are probably the ones trying to rent them to you!
Is anyone still using G.729? We used to back when bandwidth was scarce, but all our endpoints have been G.722 for at least the past ten years. Agree transcoding is one of the heaviest aspects of an Asterisk setup, but even that is not very heavy on modern hardware. We run most of our hosted PBXs (the ones with less than 50 endpoints) on a single core ESX guest (also with 2 GB RAM) and have never had capacity issues.
The thing is that “VPS” is very generic - what you get in practice depends on how oversubscribed the physical server is, so it would be hard to have a clear-cut rule - depends a lot on the provider and how lucky you are with your neighbours.
For Qm Live, we run a number of different DC deployments in various countries, some on public clouds and others embedded within large customers, and have thousands of servers currently provisioned. In theory, each VPS has the same specs. In practice, not really so, and we ended up creating a large monitoring layer to understand what happens in realtime.
Sometimes you have to drop one of them, re-create it, and it works better. Sometimes you have to change provider. Bottom line: make a very conservative estimate and keep monitoring.
It spikes a little bit during call setup - maybe 50-60% but once the calls are established, it settles down to about 10-17% - It’s just passing packets at that point, so it is not a chore for the VM.
