Shulou(Shulou.com)06/02 Report--

After graduation, I joined the audio and video product department of a large Internet company to do background development. In fact, I studied automation, the direction of graduate students in embedded systems, but a little knowledge of the Internet, so I am very lucky to be able to enter such a big company.

The first half of the year should be the happiest time in my last job, when more than a dozen of us were drawn out to be friends, and team leader Z was in charge. From product to development, most of them are new employees. Pm draws a big cake, and everyone is full of hope. To cut the gossip, let's first introduce the server framework that is just used in background development.

The first contact is called udpserver. As the name implies, it is a service framework that only supports udp. Because our department makes audio and video products, audio and video data requires high real-time performance, so udp is commonly used to transmit data. Udp server is a synchronous multi-process model that consists of 1 Interface process and multiple Worker processes.

The Iterface process is responsible for receiving requests from the outside, doing some legitimacy checksum format conversion, and forwarding them to the back-end Worker process. The Worker process listens to different ports to receive packets and handles business logic. The return packet of the Worker process is sent directly to the client.

There are several points worth paying attention to here:

First, the Worker process listens on different ports.

It is obviously more common to listen on the same port, and it is important to note that the listening port socket must be inherited from the parent process rather than the socket created by Worker itself. Because the former kernel can guarantee the scheduling uniformity, while the latter has no such effect, the kernel will only throw the request packet to the same Worker.

The reason why we use the scheme of listening on different ports is to ensure the controllability of scheduling. The Worker to which the request packet is sent is expected, a more personalized scheduling strategy can be made, and the problem location is much more convenient. Udp server is scheduled by polling by default.

The second point is that the Worker process returns packets directly to the client.

Another common practice is to return packets through the Interface process, but the disadvantage is that Interface becomes a bottleneck. The disadvantage of Worker returning packets directly is that it exposes Worker to the outside world, but this problem is not very serious. In contrast, we prefer to achieve a performance improvement. In order to return a packet to the client, Interface encapsulates the client's ip and port into a request packet and sends it to Worker.

Although the framework is simple, but the performance is very excellent, as an echosvr performance can reach 30w + QPS. However, this framework does not support TCP, so it can only be used as an internal service framework.

Because this framework has not been used for a long time, the above may be inaccurate or inadequate, please do not hesitate to comment.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.