The only way to optimize for massive concurrency is to make the most efficient use of every part of the resource.
Allocating fixed resources according to the steps of the business process, rather than according to the business itself, will make every part move. Or qualitative optimization, or evolution into new technology.
At the end of the pipeline, let's give a few examples.
Circuit Switched & Packet Switched
- Each service occupies a line until the end of the service, which is circuit switching.
- Reversing it, cutting all services into slices and assigning line time slices to those slices, this is packet switching. The
effect
It is this simple upside-down transformation that promotes the formation, development, and prosperity of the Internet.
Why is the capacity of packet switching large, because in circuit switching, for a single line, only a small part of the resources are used at each specific moment, and other resources are wasted due to idleness
Then look at others.
Batch system & time-sharing system
This is almost the same as the relationship between circuit switching and packet switching above:
computer resources are fully utilized by all users, and each user may be using different resources of the computer, so these users seem to be using the computer at the same time. Users can share computers together without having to wait in long lines.
The above are the contents of the first and second chapters of the computer network and computer operating system textbooks, but few people connect them. But they are actually the same thing.
Interestingly, it was the time-sharing system that affected packet-switched networks, not the other way around. The idea of packet switching existed as early as the 1920s, but there was no successful case at that time, so the idea could only be left on paper.
With the development of computer system technology, packet switching has a template that can be imitated. Since multiple users seem to be using the same computer at the same time, the data transmitted by the computer to the remote users can also seem to be using the network line at the same time.
The following case still follows this line of thinking.
flexible frame transmission
This is actually the same thing, look at the picture below:
to explain further
:
For example, if 10 frames have a delay of 100ms, the fixed part of each frame of these 10 frames can be grouped into a packet, a total of N data packets, and the N data packets are sent out in random order within 100ms, and the receiving end is fixed Calculate how many you receive within the time, then decode and splicing, you can play. Even if the packet is lost, since the N data packets are randomly sent out of order, it is just blurry.
Isn't it fun? This is flexible lossy transmission.
Why is the throughput better than direct frame transmission, because direct frame transmission involves FEC or ARQ, and the redundant or retransmitted part is necessary for decoding, which wastes bandwidth resources, while flexible lossy transmission avoids resource waste.
Then go.
Apache & Nginx
It’s an old-fashioned topic, and it was analyzed when the business layer was involved in transmission optimization:
https://blog.csdn.net/dog250/article/details/78994710
Let’s unify it with the ones discussed above:
Is
it right? a thing? assembly line?
Then look, there are.
wireguard-go & boringtun
Related wireguard-go, the performance is very poor, no matter how optimized, various indicators still pull the crotch, but boringtun is quite good. This is not a black technology optimization, but an architectural change.
boringtun no longer generates a goroutine per peer, but only generates CPU threads to process all peers. wireguard-go is a lot like Apache, and boringtun is Nginx.
Whether it is a request or a peer, there is a problem of scalability, and it cannot be used as a granularity for cutting resources. If it is, it is destined to lose scalability, and eventually the management overhead including scheduling will overwhelm the system.
Remember, it's important to realize that resources are fixed, don't let loose requests schedule resources, but let resources schedule requests. The large-scale concurrency problem is essentially a search. To make this search optimizable and observable, the search is a matter of the data plane of the business itself, not to the system as the control plane.
In other words, you are looking for requests, rather than throwing the blame on the system to find processes or coroutines.
Then look, there are.
iptables & ipset & nf-HiPAC
iptbales has been criticized, everyone knows that it has poor performance under massive rules but does not know how to optimize it. In fact, it is very simple, just preprocess the rules.
I won't go into details on how to preprocess the rules. The easiest way is to put the IP address into the ipset instead of writing multiple rules. For more complicated ones, see:
https://blog.csdn.net/dog250/article/details /77618319
also has an nf-HiPAC, which I played years ago, and the comparison between it and iptables is like the series of comparisons listed above:
interesting.
It's all the same thing, or reverse the order.
Workshop & Assembly Line
If there is no assembly line, with those workshops alone, it will be difficult for the large-scale machine industry to develop, and people will not be able to enter the era of consumption.
The workshop is to do one job one job, and then do the next one. The pipeline is to divide each job into a fixed N steps, and the N steps are relayed. Although the production cycle of a single product does not change, the total throughput can be expanded by N times, thanks to the full utilization of resources. This is exactly the same as time-sharing systems and packet switching.
The following is an explanation of why the pipeline has high throughput:
Take
a web server as an example, Apache is like a workshop, and a worker is allocated to serve the whole process when a request comes, and Nginx is like a factory, scheduled to a fixed pipeline. In fact, all of the above examples in this article can be applied.
In short, there are so many resources, let them all move.
The more times each part of your code runs in a fixed time period, the more efficient it will be. If the code does not run, take Apache, wireguard-go as an example, this is the so-called scheduling overhead: the system schedules you, you But a lot of code did not run.
Recently, I was thinking about some common things, and took some time to summarize. When it comes to luxury goods and mass consumer goods, the latter's production focuses on high throughput and high concurrency, such as Wenzhou leather shoes. But for luxury goods, it is more suitable for the workshop model, and the special person fully tailors it, such as the manager's trousers.
Wenzhou, Zhejiang, the leather shoes are wet, and it will not get fat when it rains.