{"id":22123,"date":"2022-02-21T11:57:21","date_gmt":"2022-02-21T10:57:21","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=22123"},"modified":"2023-06-18T17:48:49","modified_gmt":"2023-06-18T15:48:49","slug":"scaling-a-basic-chat","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/02\/21\/scaling-a-basic-chat\/","title":{"rendered":"Scaling a Basic Chat"},"content":{"rendered":"\n

Authors: <\/strong>
Max Merz \u2014 merzmax.de<\/a>, @MrMaxMerz<\/a>
Martin Bock \u2014 martin-bock.com<\/a>, @martbock<\/a><\/p>\n\n\n\n

The idea of this project was to create a simple chat application that would grow\nover time. As a result, there would be more and more clients that want to chat\nwith each other, what might lead to problems in the server that have to be\nfixed. Which exact problems will occur, we were going to see along the project.<\/p>\n

In the center is a simple chat server that broadcasts incoming messages to all\nclients. In order to notify the clients about new messages, the connection\nshould be static and bidirectional. Therefore, we based the communication on the\nWebSocket protocol.<\/p>\n

Furthermore, wanted to see how the server behaves with the rising load.\nTherefore, we had the plan of performing several load tests to display the\nweak points and improvements, as the system enhances.<\/p>\n<\/div>\n\n\n\n\n\n\n\n

Creating a Concept for (Monitoring) A Load Test<\/h2>\n

We started this project with creating an overview over all the things we will\nneed. First of all we needed a client that can be used to chat and a server that\nis capable of broadcasting messages to all connected clients.<\/p>\n

Load Test Client<\/h3>\n

In order to perform load tests, we need a lot of clients that can send a lot of\nmessages to the server. Since we don’t have a bunch of people that are willing\nto chat, we have to automate the process of creating and operating the chat\nclients. Since we wanted to use WebSockets and no public load testing clients\nwere available, we had to implement a load test client by ourselves.<\/p>\n

First we implemented a basic chat client that was just there for connecting to\nthe server and for sending and receiving messages. The first version was just\na basic command line client. The tool asks you for a username and afterwards\nyou can chat with other clients.\nIn order to automate the dispatching of the messages, we added a loadTest<\/code> flag.\nAdditionally, you can configure the message frequency and size.<\/p>\n

To start a bunch of clients at once, we created the load-test-client. Here you\ncan see a screenshot of the flags that can be used to configure the load test\nclient.<\/p>\n<\/div>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Furthermore, we wanted to collect metrics from the clients that could provide\ninformation on the performance of the system in general. The collected data will\nbe written in a CSV file that we can use after each load test to analyze the\ntest by calculating latencies and the ratio of sent vs. received messages, and\nfinally render graphs of the calculation results.<\/p>\n<\/div>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Server Monitoring<\/h3>\n<\/div>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

We wanted to monitor the server using the popular Prometheus\/Grafana stack.\nFirst of all, we used cAdvisor to access the hardware metrics of the docker\ncontainer that runs the server application. Additionally, we used the Golang\nclient for Prometheus to provide custom metrics. The metrics we wanted to\ncollect were the number of incoming and outgoing messages as well as the\nprocessing time (time from receiving a message at the server to sending it to\nthe last client) for each message.<\/p>\n

Finally, we configured two Grafana dashboards to display all the collected\nmetrics.<\/p>\n

Restricting the server<\/h3>\n

With the intention of running into scaling issues very quickly and only having a\nlimited server capacity available at the university, we wanted to restrict\navailable CPU time and memory. After some research, we found out that there are\ntwo possibilities to restrict the resources of Docker containers:<\/p>\n