High-performance access sever development optimization

We have been engaged in the development of high-performance backend services for two years. The major support for this service is 100% CPU access in S. This data was obtained in the ultimate server test a few days ago. In fact, the speed of the backend server depends on the type of its service. A few pieces of data are like this.

Memory Access: 300 W/S. That is, the US level. Access 300ns once.

Sock access to the US level.

Disk access in ms. Including databases.

If you only rely on access to the memory, your server should process 30 W/s of access to meet the requirements. This will be followed by the epoll framework with the notification mechanism and high concurrency capability of FD. When kernel-level optimization is performed at the network layer and the lock in the kernel is removed as much as possible, the access speed should be increased to 40 W/s or even 50 W/s.

The key to high-performance access is network access performance and efficient notification mechanisms. The following principles must be used to process high-performance networks:

1. Do not lock part of the network.

2. The single process is three times more efficient than sharing, and the network throughput is greatly reduced by locking.

3. Use the memory for temporary data storage. The memory management must be pre-allocated. Find any piece of memory to achieve O (0). The memory management algorithm. Here we will study it. What I am dealing with is the high-concurrency access machine of the distributed system, which also involves the routing of the back-end cache server. This service is the server logic, and the design of this route is also exquisite. To minimize the routing time, you must design a reliable memory access and O (0) routing search algorithm. I believe everyone should understand this aspect.

4. Shared Memory Access is the same as memory access. However, in the actual production environment, you often need to lock the shared memory. The lock is implemented by semaphores. Now I know how cool POSIX is. POSIX is preferred for communication between processes. Tests show that the System V interface is more than 50% slower than the POSIX interface. Obviously more advanced in modern times.

5. Remove the STL linked list and vector operations in the Code and use the alternative solution. This greatly improves performance and greatly reduces CPU consumption. A good program architecture is the best way to reduce bugs. The code needs to be checked repeatedly. Access to distributed systems is multi-state. The processing of each part of the state machine is the core. The minimum cost for each request is required, which requires a lot of brains, including code reduction and function calling. Many System Call codes are implemented in simple ways.

6. Reduce the time functions to be used. The cache system time is a very good optimization. Using the time for the entire processing process can reduce the CPU usage by several times by 10 percentage points. Reduces the number of calls to system space and user space. If you are interested, you can check the kernel code. The Linux time is inaccurate, and the time needs to be locked. Enter the kernel space to read the CMOS clock data. Every update of the system time is an atomic operation.