.svg){kind=small}
What are you searching for?
High load systems became a trend back in 2012. But there's a problem with them - we still have no clear definition of the term. Where do high loads start? Are 10 requests per second already high load or not yet? And what about 100 requests or 1000? You might be surprised, but the numbers are not the point here at all.
First, it is important to understand one simple axiom: high loads are a relative concept. They cannot be measured by the number of requests that arrive at the server, or by the speed of the website. After all, there is no “average” number of requests, as well as an “average” site. One web resource will be able to process a thousand requests per second without any difficulties, while the other will crash on the hundredth connection. So the point here is not at all in quantitative indicators.
Let's try to understand what high load is.
High load means the resistance of an Internet project to high loads. But wait, there’s more. This is not some universal piece of code that we copy-paste and after which everything flies. This is setting up the site architecture: working with databases, a server, using modern technologies and programming languages.
If we draw an analogy with an ordinary clothing store, then instead of servers, programming languages and IT stuff like that, there is a simple and understandable consultant, cash register and goods. On a typical day, a consultant approaches each client, helps to choose the size, advises accessories, then escorts to the checkout and calculates the buyer. Two or three consultants can do it quite well.
And on Black Friday, the store is attacked by 50 buyers at once - and their number does not decrease. According to the usual pattern, consultants walk next to each one, guard the customers at the fitting room, run after a desired size. At this rate, only 5% of those who potentially will leave the shop with purchases have a chance to be served well, and even that number can only be reached in the best case scenario. Hence, less profit for the shop and less customer loyalty. It is clear that the consultants’ work needs optimizing. The same holds true for the site - if it does not cope with such a number of requests, рit's time to change something.
Does this ring any bell?
We have compiled the most popular high load definitions from IT professionals and users who are knowledgeable in this topic:
The last definition allows you to look at the definition of high load from a new angle:
“This is a system that is constantly scalable and has enough resources to work with current loads.”
Since the "what is high load" question has already been clarified, let's move on.
High load infrastructure processes large volumes of data and thereby generates great value for a business. Due to this, failures and other quality problems result in the extra cost for companies. Thus, according to the Gartner article, the loss of large online services reaches $ 300,000 per hour in case of downtime.
A key source of problems in high load infrastructure is the volume of data, complexity and rate of change. Therefore, it is important that the overall high load architecture of a large application should be designed both in terms of the software components and the hardware on which they operate. Moreover, when designing a custom high load system, it is necessary to understand clearly what delivery times are set, what legal restrictions are, how much experience the specialists involved in the design have. Besides, we should be fully aware of the associated risks and their acceptability for the company.
After that the next stage will be to try and answer a number of questions:
If you decide to create high load applications (primarily in the field of web technologies), it is important to take into account a number of principles.
Uptime is directly correlated with the reputation and performance of many companies.
The speed of a web resource affects user satisfaction with the service, as well as ranking in search results (which is reflected in traffic).
The request should always return the same data to users so that users are sure that if some data are recorded/entered into the system, during subsequent extraction, you can count on their invariability and safety.
We can talk about various parameters of the system: how much additional traffic it can handle, how easy it is to increase the storage capacity, how many transactions can be processed in excess of the current capabilities.
The development of a custom high load system that is easy to operate is extremely important at later stages of project development (easy diagnosis and understanding of the essence of problems when they arise, easy updating or modifications).
Includes hardware and software costs. It is important to take into account other aspects necessary for the deployment and maintenance of the system: the amount of time spent by the developers on assembling the system, the amount of effort required to start the system, training, staff training, etc.
The main problems in the design of custom high load systems arise in the following segments: data volumes, data dissemination, data correction, use of open-source software, search, processing & analysis of data and information modeling.
Important: You need to pay more attention to the reliability of high load systems. Reliability means the ability of the system to continue to operate normally even in case of a problem. The problems that arise are called failures, and systems built with them are called failures, too.
Talking about the reliability of high load systems, it is necessary to mention the fault management documentation. Well-written crash management documentation should include a simple step-by-step guide to recovering your system from almost any possible crash.
When it comes to large data centers, hardware failures (be it power outages, hard drives or RAM fail) are known to happen all the time. One way to solve the problem is to create a non-shared high load architecture. Thanks to this architecture, there is no central server that controls and coordinates the actions of other nodes, and, accordingly, each node of the system can operate independently of each other. These systems do not have a single point of failure, so they are much more resilient to failure. Another method to prevent failures is to increase the redundancy of individual system components to reduce failure rates (redundant power supply, RAID — redundant array of disks, etc.). When one of the components fails, the spare component takes over its functionality. In this way, a failure cannot be completely avoided, however, the option is quite acceptable in most cases, since it is possible to restore the system from a backup in a short time.
If we talk about global redundancy, then all the rules of interaction between servers also apply to data centers - we must have a margin of safety (capacity, computing power, etc.) in order to continue to work with the loss of one data center without significant damage to quality services provided.
To ensure system reliability, it is recommended to use the following approaches:
Important: The application scales as efficiently as its weakest component, so we must remember to identify such places. Try to design a custom high load system taking into account the future scaling and monitor everything that happens to the equipment through a well-implemented monitoring system for system components.
If we talk about web applications, then these are thousands, and sometimes hundreds of thousands of people. Of course, a specific figure cannot be called. But it is clear that an online store that processes 10 requests per day cannot be called a high load, but Facebook, Amazon, Flickr, MySpace or Youtube certainly can.
If the application has to process huge amounts of data, which is also constantly growing, one server is not enough. The largest high load app solutions like Google or Facebook work on hundreds of servers.
But a huge number of machines are caused not only by high loads. More precisely, not only with a large number of requests that have to be processed non-stop. At the same pace, the servers quickly fail, so the more there are, the higher is the likelihood that the system will quickly recover after a failure.
If an online-offer is valuable for users, its audience is growing. Therefore, the high load is not just a system with a large number of users, but a system that intensively builds an audience.
If a person enters a search query on Google, uploads a video to YouTube or makes a purchase on eBay, they expect to receive the result immediately. If the system takes a long time to respond, most likely they will start searching somewhere else. Therefore, instant response is a distinctive and very important feature of a high load system.
This item is directly related to the previous one. To give an instant response, the system goes through a lot of resources - CPU, RAM, disk space, etc. And for this, it is necessary that the resources: a) be free and b) be in sufficient quantities (preferably even with a margin).
Here we come to the paradox of high load systems: the faster they grow, the more stringent it is to control resources. When an application grows its audience, the number of requests naturally grows. And the number of resources that need to be spent to maintain interactivity also grows with them.
That is, the high load is a system that needs to be constantly scaled. Setting it up to work in this way is quite difficult, but from a business point of view it is worth it.
In general, it is necessary to determine two major things. The first one is how large the audience that the project can face is expected to be. Secondly, the project will have to work with a structured data set, so the second important thing is to understand how large and complex this structured data set is going to be.
But it's better to start from the types of projects, for which using the high load approach is highly recommended:
Information resources: in the overwhelming majority of cases, the key point here is that there is no need to plan the high load architecture in advance, a very small amount of information resources outgrows the capabilities of one server with a well-tuned content management system. And even if this happens, adding new servers will be painless due to the wide possibilities for caching content and no need for complex solutions at the DBMS level.
Online stores: everything here rests on the breadth of the assortment - if the assortment theoretically cannot grow to hundreds of thousands of items, then no special decisions will be required. Otherwise, you need to think about efficiently caching frequently visited products and categories, as well as minimizing "heavy" queries to the database.
Social networks: the main criterion is the theoretically possible number of participants and the connections between them. If we are talking about a small regional or narrow-topic social network, then you can easily put everything in a relational database, but for something bigger you will need a scalable solution.
Technological projects: projects based on technical know-how directly depend on it and, as a rule, already at the stage of designing the "highlight" of the project, it becomes clear which architecture is more suitable for it and how to develop it in the future. High load application architecture.
Architecture is the foundation of an application. And as in construction, the quality of the house depends on the strength of the foundation, the success and viability of the system in the development also relies on the same.
In our decisions to use or not to use high load systems, we focus on what a particular business needs. But there is also planning - something that the business does not see and from which it does not directly benefit. When it comes to high load applications, it is not enough to develop a competent architecture, you also need to build a monitoring system nearby that will monitor the viability of components, the speed of reaction, generate and display data to monitor the health of the high load system.
The cost of developing a monitoring system can take up to a third of the total cost of creating a high load application. But without it, it is difficult to build a reliable high load system.
Business, unfortunately, does not always understand what it is for. Why pay money for additional functionality that is not required for work and does not make a profit? There is quite a justified desire to save money, but saving on monitoring when it comes to high load is not the best idea.
What will happen if the monitoring system is not implemented in a high load system?
A high load application can behave unpredictably and stop working in the most unexpected place. Moreover, the system will do this at the time of peak load: at the time when the business earns the most. Therefore, saving on the monitoring system is illusory. If you abandon it, you can end up losing a lot of money.
Initially, the cost of the hardware part of a high load system is considerably higher than the cost of a conventional application. If you inflate it with flexibility, the amount of equipment required will multiply. The rigidity of the system solves the problem of increasing resource costs, and we do our best to balance the high app performance of the system and the capital budget.
Knowing about the problems of scaling and the increasing load on the integration layer, we work out the most economical long-term development strategy in advance.
Why is it important? Let us consider an example of the wrong strategy, when it is decided, if the need arises, to horizontally scale some part of the system infinitely.
It seems that there is nothing wrong with this approach. But in reality you will first need a server for 0.5 million, then a more powerful one for 3 million, after that for 30 million, and the system still will not cope. And even if you agree to pay further, sooner or later there will be no technical way to solve the problem.
Bottom line: you have thrown away a lot of money, and eventually you are left without a decision and will have to make a system from scratch. That is why the strategy - understanding how the system will be refined - is developed by our specialists in advance.
Before starting work, we always ask the client a question: what is the main thing in the system for him? And we use 95% of our resources and efforts to implement this, leaving little things “overboard”.
The 95 percent percentile rule applies here. The bottom line: you should not try to solve all the problems, you need to work on 95% of the functions, and consider 5% as special cases that lead to the complication and rise in the cost of the system.
We help our clients separate the wheat from the chaff to get the most useful product and save their money.
We always start with a detailed study of the client's business requirements. Having understood the process, we will show you how to build a high load system in the best way. We will point out the critical points and give recommendations on what really needs to be done and what is better to avoid. Along with developing a strategy, we will offer not only the optimal technical solutions but also economic ones.
Attention! It is important to bear in mind that high load development is unthinkable without daily qualified support from DevOps engineers with relevant experience in developing complex multi-component solutions and administering servers and system services.
High load projects developed by Geniusee specialists on average withstand user traffic, exceeding the planned indicators by 2-3 times or more! This ensures that your site or application will not crash even during the peak of high loads and high traffic of users.
The specific character of high load systems lies in the fact that you cannot work with them like with any other system. As a rule, special attention is required when optimizing high load. Hundreds of interconnected settings can both "help" the system and spoil its work. The job of a specialist is to choose the right parameters so that business tasks are performed successfully, and for this, you often have to study new materials, use previous experience, conduct many tests, and so on.
If you are looking for high load system development services - just fill out the contact us form.
