So, I have this customer whose cluster was behaving very well until one day I got a report that it was very slow, it was not answering any SIP signals right away. If you put a sngrep, you may get something similar to the following behaviour.
The SIP signalling arrives, but the server delays a lot in answering it. Sometimes it is very long that the endpoints start timing out.
What is causing the FreeSWITCH Slowness?
In this very specific case, the fault was on the Amazon RDS burst parameter. This means that there is a quick-answering query quota. Once you reach it, the database performance goes slow. If you are not using Amazon, but any other database-managed system (Google, Azure, etc), look for a similar parameter.
How to Fix the FreeSWITCH - RDS Slowness?
There are two ways:
- disable the burst limit, if money is not an issue. Usually, data centers bill more for rush queries (Amazon does).
- create a small VPS (read above).
Creating a Small VPS to Host the FreeSWITCH Database only
The following diagram tries to explain the solution itself.
So, why a server outside of the RDS? Do not forget that this tries to save money because of the burst queries. So, keeping that in mind, the freeswitch database is a pure operational database. If the database content is deleted (you delete the tables), the next time FreeSWITCH restarts, it will re-create them. So, there is not a big reason to keep a redundant database architecture such as the RDS.
The operational database (freeswitch database) is small if you compare it against the fusionpbx database hosted in the RDS. A VPS with 2 vCPU, 2 GB of RAM and 25 GB of space is more than enough.
If you were wondering what kind of information it is hosted, in general, is the status of all FreeSWITCH elements, such as:
- registrations,
- presence,
- channels,
- queues,
- current calls,
- limits, and
- others.
Each time an extension sends a REGISTER, UPDATE or SUBSCRIBE signal, Freeswitch hits that database, updates the information and answers. In my opinion, there is no need to have that in an RDS environment, but do not forget to have a contingency plan in case the server crashes. You may put want to have a cold backup with monitoring that restores the image in case of a hard disk failure, for example.
If you take my advice on this approach, make sure the I/O of the hard disk is fast, you may want SSD instead of HDD, the fastest CPU possible and please, please don't use that server for anything else. It is very tempting to try to be resourceful, but this database needs to answer with no delays.
Good luck!
";