This article references www.ttalk.im/topics/63?f…

The Erlang process consumes EMQ’s policy of separating the link process (EMqtt_client) from the session process (EMqtt_session) for client links. When an MQTT client is connected to the EMQ server, a process (EMqtt_client) is established to manage the connection. After the client is validated, another process (EMqtt_session) is established to manage the session of the client. In EMQ, each clientID can only be logged in once. Therefore, the client that logs in later will kick the client that logs in first. When a client successfully completes validation, EMQ adds a table item to the MQTT_session, Table items are also added to the MQTT_LOCAL_session and MQTT_client ETS tables. The process context link process (EMQTT_client) is responsible for receiving the data sent by the client and receiving the data to be sent to the client from the server, and uses the codec to encode and decode. Therefore, the context consumption of the link process mainly depends on the size of the received packets and the size and quantity of packets to be sent. The session process (EMqTT_session) keeps an INFLight queue to reply and wait for messages whose QoS is greater than 0. By default, 32 messages are saved and waiting for reply. If the number of messages exceeds this level, they are put into the waiting queue. Therefore, the main memory consumption of the session process (EMQTT_session) depends on how many messages are waiting for replies and the size of the packets that need replies. The main CPU consumption timer link process (EMqTT_client) starts a heartbeat timer by default and periodically checks whether the link is alive. The session process (emqtt_session) also starts a resend timer to check infligt responses for messages with QoS greater than 0, and another timer to check REPL responses when the client advertises messages with QoS greater than 2. Of course, the session process (EMQTT_session) may be held for a period of time after the client is offline. Therefore, a timeout exit timer is set up during this period. Therefore, the session process (EMqTT_session) has three timers at the same time. Monitoring session processes (EMqTT_SESSION) To detect the exit of linked processes, a monitoring is established for linked processes. When adding items to THE TWO ETS tables mqTT_LOCAL_session and MQTT_client after the successful launching of the client, two monitors will be established respectively. Used to monitor the exit of the session process (EMqtt_session) and the linked process (emqtt_client). Process messaging is inevitable because EMQ uses a separate policy of linking processes (EMqTT_client) and session processes (EMqTT_session). This is because the session process (EMqtt_session) is responsible for receiving the message sent by the server to the client, processing it in advance, and then delivering it to the link (EMqtt_client). When persistent sessions are used, a large number of process messages are generated during the search and recovery of the session process (EMQTT_session). Summary From the above introduction, you can see that before deploying an EMQ server, you need to consider the average message magnitude of a client, QoS ratio and packet size, and make CPU frequency and number choices based on how many clients there are (see the scheduling section of the Actor model). When running an EMQ server, if there is a sudden CPU surge without significant changes in the message magnitude or number of clients, consider whether there are frequent client downlines. Of course, this is only a simple example, and there are many other cases that are not listed here.