How does the chat work?

Imagine a situation when a service has 1000 rooms of 50 users in each one. How does the chat behave under such a load? The required resources and architecture of microservices is as follows.

The basis of the chat is the exchange of data between the browser and the server while sending and receiving messages through a permanent connection. This connection is provided by WebSocket technology (WebSocket Protocol). It is especially good for services that need constant data exchange, such as online games, real-time marketplaces, etc.

Through these protocols, all users connect to the comet server CppComet, which is powered by comet technology. It is written in C ++ and is multithreaded, so it can handle a heavy load. CppComet provides an API for sending messages from the chat backend to the frontend via websockets, that is, a description of the sending process. In general, an API is a set of functions that describe the conditions for interaction between two programs or two sites.

The chat backend is written in PHP and designed as a plugin for the October CMS. This platform provides a convenient admin panel, functions for working with site files and many other additional plugins that you may find useful. In addition, October CMS is a fairly flexible and fast system based on Laravel. This does not slow down the code as compared to writing the code without using the CMS. October CMS also provides a caching mechanism to choose from: Redis, Memcached, or file cache.

The chat frontend is written in JavaScript using JQuery. MySQL or MariaDB is used to manage the database.

Load testing of the chat was carried out. But the behavior of users will significantly affect how often they send messages and switch between dialogs. If the user is online, but does nothing, then he only slightly loads the server. If it takes active actions, sends messages, then its requests must be processed by the server and the messages are stored in the database. These articles describe the chat load testing mechanism and test results. One inexpensive server can handle all this load.

There is another great mechanism built into chat - chat caching in the Indexed Database API. It is a database that can be used inside any browser to store large amounts of data. When switching dialogs, the user gets the result from the local cache of his browser instantly. And then, in the background, a request is sent from the server to check for messages that were not in the cache. This mechanism allows the chat to work even when there is no internet connection. The correspondence data will simply be retrieved from the cache. And if the user writes a message, then it will go to the browser cache and will be transmitted to the server in the background when the network resumes. As a result, thanks to the caching of all messages and dialogs in IndexedDB, the user almost always receives a response instantly even before the server processes it. And, if the server is overloaded, then the message may take a little longer. But the chat itself will still work.

If the chat works on a Cordova application, then files in messages (images, audio, etc.) also get into the cache and the application works like a standard messenger.

There is also a real project with a real workload for 130,000 users, who have a lot of dialogues and 2 GB of photos and other files per day. And chat does a great job with it. Also on the GisAuto website a chat based on CppComet is installed. It works stably and there were no serious problems during the year of operation.

Another articles:

Posted in Blog on Sep 28, 2020