Several steps to optimize a server

Recently I wrote a server, and the business logic is very simple. Each Protocol Package reports data to the server. Each packet may have N pieces of data to be stored in the database. obviously, this business logic cannot use caches like memcached, because each piece of data is relatively independent and must be saved to the database. aside from the basic I/O models of the server, let's talk about Several optimization steps for this server.

1) simplest Processing
The simplest process is step-by-step. Every piece of data is honestly inserted into the database. obviously, the efficiency is low. If the concurrency is large, the mysql load increases, and the server is blocked in the database operation, resulting in slow connection processing.

2) Step 1 Optimization: insert data quantitatively
The basic model remains unchanged, but not every data is inserted, but cached. after a certain amount of data is accumulated, the data is inserted into the database. this method cannot be greatly improved than the first method.

3) Step 2 optimization: Enable thread processing to insert data into the database
Here, one more thread is used to insert data into the database, and a buffer zone is opened up. The main thread keeps pouring data into the buffer zone, and the secondary thread is responsible for importing the data in the buffer zone to the database. the pseudo code indicates that the optimization is like this: main thread:
Add data to buffer A (note that no lock is required here)

Sub-Thread
Lock
Swap the pointers of buffer A and buffer B so that buffer B points to the original Buffer A and buffer A points to buffer B.
Unlock
Import data from buffer B to the database
Clear buffer B

This optimization efficiency has been greatly improved. The main thread only needs to communicate with the client to receive data from the client. The secondary thread only needs to import data into the buffer zone, you do not need to care about communication issues. in this way, the main thread will not slow data reception and new connections due to slow data insertion. because of multithreading, data sharing between the primary and secondary threads is easy to achieve. When the primary thread inserts data into the buffer zone, no locks are required, when the sub-thread is dumping data, you only need to lock and then adjust the pointers of the two buffers (I suspect this lock can also be avoided ). they perform their respective duties without harassment, which is simple and efficient.

4) Step 3 optimization: evenly distribute the data imported to the database as much as possible
This step is roughly the same as the previous step. It only sets a volume when the sub-thread is dumping data. When the counter reaches this volume, the sub-thread sleep for a while (such as sleep for one second ). the advantage is that the data import time to the database can be evenly distributed as much as possible to reduce the pressure on the database at the peak time.

5) Step 4 optimization: optimize the database
Because the server only needs to insert data into the database, you can consider caching the data in the same table during the insertion, and then writing it in an SQL statement to insert the data together, this reduces SQL statement calls, IO, and efficiency. I am using mysql. For more information about optimizing mysql Data insertion, see here.

After these optimization steps, the server efficiency is greatly improved, not only the server efficiency is improved, but the overall system IO and database pressure are also reduced.

The following is the split line:
-------------------------------------------------------------------
I thought about it for a moment and thought it was possible to remove the lock...

My buffer is a list of STL, and the main thread keeps pushing h_back to the list.

The swap operation in STL is called when the buffer is switched, that is, switching the header nodes of two linked lists.

From this point of view, we can indeed save the lock steps.

--------------------------------------------------------------------
The next day, I decided to lock the lock. because there are not many operations in the critical section, I don't think the efficiency has much impact.