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.
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.
There are two ways:
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:
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.
So, I will talk now about my experience with Telnyx. There is not too much I can say to introduce this company. Just another one of the top in the market. I know them because one of my customers use to deal with them using their termination trunks.
I will try to tell you what happened with my approach here.
When coding telegram bots, one of the things you will find is that each HTTP query that the system does to your code is independent and sessionless. The Telegram API does not provide a way to remember things; it is up to you to do that.
Why remember? Useful bots are not those where you answer one question and they give you an answer, and then you ask the same question and they give the same answer. Bots have to evolve and remember your last actions; you may want to have a bot that chats with you, it needs to remember your name and so on.
Fortunately for us, PHP has sessions, an easy way to have a memory of what happens. PHP sessions out of the box won't work with Telegram bot; when a browser interacts with a PHP script that uses sessions, the browser uses a cookie to name the session and PHP automatically gets it. In this case, you are attending a headless client that doesn't support the cookies. Here is what I did.
This article assumes knowledge of the Longman PHP Telegram Bot library. Which in my opinion is the best PHP library to write Telegram bots. Also note that this is a short-term memory solution, it is not meant to be long-term.