FreeSWITCH Cluster Slowness when having an RDS

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 to answer it. Sometimes it is very long that the endpoints start timing out.

What is causing the FreeSWITCH slowness?

In this very specific case, Amazon RDS has a 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:

1. disable the burst limit, if money is not an issue. Usually, datacenters bill more for rush queries (Amazon does).
2. create a small VPS (read above).

Creating a Small VPS to Host 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 in a redundant database architecture such as the RDS.

The operational database (freeswitch database) is a small database 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 a SUBSCRIBE, Freeswitch hits that database, it updates the information and it 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!