Problems with load growth

As the load grows, your well-designed program may encounter a lot of unexpected problems: the original stability of the system will be broken, and we will examine these problems. Of course, you can expand horizontally or vertically, or you can choose to write better programs that allow your system to handle higher loads. This will save you more hardware and make your entire application more reliable with faster response times. For programmers, this is bound to get a lot of satisfaction.

A large number of objects

When the number of objects in the system grows to a certain extent, we usually face the problem of scale. As the number of objects grows, it is obvious that all types of resource overhead can be stressful.

Persistent failure produces an infinite event stream

We do not have time for system recovery in the case of a large network failure scenario. Because we are always in a constant state of stress.

A large number of high-priority tasks

For example, gravity-separation routing (rerouting) is a high-priority activity. If there is a large number of shed or cancellation (squelched), the resource will be consumed continuously to support high-priority tasks.

Larger Data flow

As media resources grow larger, the load on the system increases. The system load increases as the number of requests from the source grows.

Feature changes

The vulnerabilities in the system are also exposed when more functionality is added outside the original design of the system.

Growth of the client

More clients mean more resource consumption. You need to set up threads to push events for the client, client queues consume memory, traffic consumes bandwidth, and you need to maintain a separate piece of data for each client.

Design decisions that are not good enough

Here are some design issues that can exacerbate the scale problem.

The design does not consider handling a large number of objects.

Lack of end to end application level flow control.

Application-level retries will result in resource reallocation and message delivery.

The overhead of an in-memory code base.

Not really reliable release.

Specific data structures are overly memory intensive.

The message protocol does not handle all failed scenarios.

Use disk as storage.

Disk synchronization does not use block replication.

Think the application layer protocol will be better.

Rely on large power consumption of the CPU to enhance the function load.

The operating system does not support process schemas. (Translator Note: This point is discussed in the original link to the comments)

Lack of hardware support for some sensitive operations, even the deletion of a single message.

Special network problems, such as ARP packets, are lost when the network load grows.

null and void assumptions

Most of the assumptions you've made are ineffective, for example, you need to use how much memory, some tasks need to run how much time, set how many timeout is reasonable, how many resources will be consumed at a time, what may happen, the system at different points of delay, your queue needs how large, and so on.

Not enough memory

The growth of memory usage baselines and the increase in memory usage spikes can lead to insufficient memory.