What is load testing. Under Maximum Load: An Overview of Web Server Load Testing Programs. Determining Maximum Response Speed

New software and other high-tech products regularly appear on the modern IT market. Determining the degree of comparability for solving specific problems, to what extent and whether they are sufficiently safe to use is possible only in the load testing mode - a service that is provided by the Getbug Engineering Company.

Stress Testing(English) Load Testing) - the process of deliberately loading a system by submitting many requests to the system or device itself, in order to determine performance indicators, response time, and check compliance with the requirements that were presented to this system or individual device

Load testing stages

Development and coordination of load models. For the model, operations that are critical for this type of testing are selected, and the intensity of their execution in the test is determined. Load profiles are determined if the application under test has different behavior patterns. Load points are calculated.
For simulated operations, load scripts are developed and the necessary data pools are created.
Script execution scenarios are developed that correspond to the load model profiles.
The operation of scripts in scenarios is checked. It is necessary to execute each script included in the script using at least several virtual users in the group in order to eliminate errors of mutual influence of scripts on each other. Scripts with insufficiently well-done correlation can also be found here.

Load testing online

Why do you need site load testing? The load on the hosting or server of your site is growing and can create a load that will be critical for the operation of the site. We perform stress testing to prevent such problems using a comprehensive stress test. The main activity of the company is aimed at monitoring the quality of developed high-tech products throughout the life cycle of their development. The services in demand are problems of test studies of interaction between a person and a software product, functional load testing and software security testing.

C ate load testing:

Assessing the performance and operability of the application at the stage of development and transfer to operation;
Assessing the performance and functionality of the application at the stage of releasing new releases;
Optimizing application performance, tuning servers and optimizing code
Selecting the appropriate hardware (software platform) and server configuration for a given application

The test bench equipment should match the production configuration as closely as possible. Especially if business decisions are made based on the operating times obtained as a result of testing. If we are talking about optimizing an application, then matching the configurations of the test bench and the industrial one is no longer so relevant. To monitor test servers, you must have access to the servers with rights to use the necessary utilities, for example, MS Windows Performance for MS Windows or sar, iostat, vmstat for unix-based OS.

Load Testing Tools and Scenarios

The first runs of tests are trial runs and allow you to understand the behavior of the system as a whole: the operation of the application and hardware. It is necessary to start testing from load points with a lower load, moving as the load increases from lower to higher. During testing, the number of load points may change and the number of virtual users entering a particular load point may change. The test results must be logically consistent and as the load increases, the results of the execution time of operations and the load of the test equipment must change accordingly. If the results are better at a load point with a higher load, then such an experiment must be carried out again in order to understand the reasons for such a “bounce”. It is possible that the load points were not designed correctly and you may need to increase the “step” size to really feel the increase in load. The set of experiments and results should be sufficient to enable an analysis of bottlenecks and draw conclusions about the performance and stability of the application under test.

Performance testing(Performance testing)

The purpose of performance testing is to determine the scalability of the application under load:

the execution time of operations is measured at certain execution rates
the number of users simultaneously working with the application is determined
the boundaries of acceptable performance are determined when the load increases
performance research is carried out at high, extreme and stressful loads

Stability testing (Stability / Reliability Testing)

Stability (reliability) testing checks the functionality of the application during long-term (many hours) testing with an average load level. The execution time of operations plays a secondary role, and the first place is taken by the absence of memory leaks, server restarts under load and other aspects that specifically affect the stability of operation.

Stress testing (Stress Testing)

Stress testing tests the performance of an application or system as a whole under stress conditions. Helps evaluate the system's ability to return to normal after the load is removed. The load can be an increase in the intensity of operations to very high values or an emergency change in the server configuration. A particular task of stress testing may be to assess performance degradation.

Volume testing (Volume Testing)

Volume testing allows you to evaluate performance as the volume of data in the application database increases:

the execution time of operations is measured during simultaneous intensive execution
determine the number of users simultaneously working with the application

According to the provisions of modern systems engineering, the testing procedure should not be the final stage in the software creation process. Errors in the process of creating such products that are not identified at the stage of their occurrence will accumulate, therefore, their timely detection and elimination is so important. The testing process itself must be applied not only to programs, but also to interfaces or electronic equipment.

Testing the functionality of the user interface aims to establish the degree of its adaptation to the requirements set by the developers. This applies equally to Internet applications and web pages. The test is subject to ergonomics, which determines human-computer interaction, simplicity and responsiveness of control, and speed of familiarization with the functions of the new software product. These are the main characteristics, the value of which determines time savings and ease of use.

The company carries out testing in several stages, which consist of:
analysis of the requirements that were presented by developers for their product and their correctness;
development of a testing checklist;
carrying out test procedures;
determining the completeness of compliance with the stated requirements for testing results;
generating a report either on the success of the test, or on identified violations in the functioning of the software product.

The purpose of checking the security level of a product is to determine its vulnerability to viruses or external hacker attacks. The correctness and reliability of both programs and equipment directly depends on this indicator. The end user must be assured that the installation of a new product will not reduce performance or compromise the integrity of the system. Security is also about confidentiality and low availability. The integrity of the system is assessed by its ability to self-heal after external penetration or unauthorized influence.

We carry out a range of work of any complexity and have a laboratory, qualified specialists and our own tools for developing and conducting test work.

Stress Testing(eng. load testing) - a subtype of performance testing, collecting indicators and determining the performance and response time of a software and hardware system or device in response to an external request in order to establish compliance with the requirements for a given system (device).

To study the response time of the system at high or peak loads, stress testing is performed, in which the load created on the system exceeds the normal scenarios of its use. There is no clear boundary between load and stress testing, but these concepts should not be confused, since these types of testing answer different business questions and use different methodology.

Software Load Testing

Term Stress Testing can be used in various meanings in a professional software testing environment. In general, it refers to the practice of simulating the expected use of an application by emulating multiple users at the same time. Thus, such testing is most suitable for multi-user systems, most often using client-server architecture (for example, web servers). However, other types of software systems can be tested in a similar way. For example, a text or graphics editor can be made to read a very large document; and the financial package - generate a report based on data for several years. The most adequately designed load test will produce more accurate results.

The main goal of load testing is to create a certain load expected on the system (for example, through virtual users) and, usually, using identical software and hardware, to observe the performance of the system.

Example 1:

A web service with shopping cart functionality is designed for 100 concurrent users who follow a certain scenario (specified actions in specified proportions):

25 users view an item and log out.
25 users add an item to the cart, check out, and log out of the system.
25 users use the product return function and log out.
25 users log in and show no activity.

In this case, load testing should emulate the typical scenario of working with a web service described above in order to make sure that the system is ready to go into production. In this case, performance indicators of the system as a whole or each node of the system in particular can be taken for analysis.

Ideally, the criteria for the success of load testing are system performance requirements, which are formulated and documented at the stage of developing functional requirements for the system before programming the main architectural solutions. However, it often happens that such requirements were not clearly formulated or were not formulated at all. In this case, the first load testing will be trial(English: exploratory load testing) and be based on reasonable assumptions about the expected load and hardware resource consumption.

One of the optimal approaches to using load testing to measure system performance is testing at the early development stage. Load testing at the first stages of readiness of an architectural solution in order to determine its viability is called “proof-of-concept” testing.

Basic principles of load testing

Below are some experimental facts, general principles used in performance testing in general and applicable to any type of performance testing (in particular, load testing).

1. Uniqueness of requests

Even having created a realistic scenario for working with the system based on statistics of its use, it is necessary to understand that there will always be exceptions to this scenario.

When Example 1 this could be a user accessing unique pages of a web service that are different from all others.

2. System response time

In general, the response time of a system follows a normal distribution function.

In particular, this means that, having a sufficient number of measurements, it is possible to determine the probability with which the system’s response to a request will fall within a particular time interval.

3. Dependence of the system response time on the degree of distribution of this system.

BY	Manufacturer name	Comments
OpenSTA	"Open System Testing Architecture"	Free software for load/stress testing, licensed under the GNU GPL. Uses a distributed application architecture based on CORBA. A Windows version is available, although there are compatibility issues with Windows Vista. Support ended in 2007.
IBM Rational Performance Tester	IBM	Software based on the Eclipse development environment that allows you to create large loads and measure response time for applications with client-server architecture. Requires licensing.
JMeter	Open source Apache Jakarta Project	Java-based cross-platform toolkit that allows you to perform load tests using JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP connections. Makes it possible to create a large number of requests from different computers and control the process from one of them.
HP LoadRunner	HP	A load testing tool originally designed to emulate the work of a large number of concurrent users. Can also be used for unit or integration testing.
LoadComplete	SmartBear	A proprietary product that allows you to perform load testing of web applications
SilkPerformer	Micro Focus (Borland)
Siege	Joe Dog Software	Siege is a load testing utility for web servers.
Visual Studio Team System	Microsoft	Visual Studio provides performance testing tools including load/unit testing
QTest	Quotium
HTTPerf
QALoad	Compuware Ltd.
(The) Grinder
WebLOAD	RadView Software	Load testing tool for web and mobile applications, including web panels for testing performance analysis. Used for large-scale workloads that can also be generated from the cloud. licensed.
Yandex.Tank	Yandex	A modular and extensible tool that allows you to use different generators internally, in particular, the familiar JMeter. This is an open-source project published by Yandex in 2012.

Key performance indicators (metrics)

One of the results obtained during load testing and used for further analysis is application performance indicators. The main ones are discussed below.

1. CPU resource consumption, %

A metric showing how much time from a given specific interval was spent by the processor on calculations for the selected process. In modern systems, an important factor is the ability of a process to run in multiple threads so that the processor can perform calculations in parallel. Analysis of the history of processor resource consumption can explain the impact on overall system performance of processed data flows, application and operating system configuration, multi-threaded computing, and other factors.

2. RAM consumption, MB

A metric showing the amount of memory used by an application. Used memory is divided into several categories:

Virtual - the amount of virtual address space that the process uses. This volume implies both the use of the appropriate disk space and RAM. The virtual memory system ensures that threads in one process cannot access memory owned by another process.
Private - the amount of address space occupied by a process and not shared with other processes.
Working Set - a set of memory pages recently used by the process. When there is enough free memory, pages remain in the set even if they are not in use. When there is little free memory left, used pages are moved from RAM to the hard disk (or other storage device such as Flash memory), freeing RAM to load other active memory pages.
Shared - the amount of physical memory used by the process, which can be shared with other processes. Although the memory allocated to a process should be isolated, processes sometimes need to be able to exchange information. Shared memory is the fastest way to interprocess communication.

When an application runs, memory is filled with references to objects, which, if not used, can be cleaned up by a special automatic process called a garbage collector. The time it takes the processor to clear memory in this manner can be significant when a process has occupied all available memory (in Java, the so-called “persistent Full GC”) or when a process has large amounts of memory allocated that need to be cleared. During the time it takes to clear memory, a process's access to pages of allocated memory may be blocked, which may affect the final processing time for that process.

3. Network resource consumption

This metric is not directly related to application performance, but it can indicate the performance limits of the system as a whole.

Example 3:

The server application, processing the user's request, returns the video stream to him using a 2 megabit network channel. The requirement states that the server must process 5 user requests simultaneously.

Load testing showed that the server can effectively provide data to only 4 users at the same time, since the multimedia stream has a bitrate of 500 kilobits. Obviously, providing this stream to 5 users at the same time is impossible due to exceeding the network channel capacity, which means that the system does not meet the specified performance requirements, although its consumption of processor and memory resources may be low.

4. Working with the disk subsystem (I/O wait time)

Working with the disk subsystem can significantly affect system performance, so collecting statistics on disk work can help identify bottlenecks in this area. A large number of reads or writes can result in the processor being idle waiting for data to be processed from disk, resulting in increased CPU consumption and slower response times.

5. Query execution time, ms

Application query execution time remains one of the most important indicators of system or application performance. This time can be measured on the server side as a measure of the time it takes for the back end to process the request; and on the client side, as an indicator of the total time required for serialization/deserialization, forwarding and processing of the request.

Our team was faced with the shortcomings of load testing tools, and, in the end, it was decided to develop our own service. Main difficulties:

If this is a service, the price is too high for a serious load
If this is a utility, the result depends on the speed of the computer/server channel from which the test was carried out
Repeated queries do not reflect real speed, since caching occurs at various levels from the CPU to the database

I hope that the “bicycle” will be interesting to others - first I will describe what is already working, then we can discuss further features.

What has already been done?

You can test tasks from the url list, up to 20 pieces
Each url can contain one or more random parameters specified using the $RND function
The test is run from multiple servers, each running only 8 threads
Testing can be conducted from 5 AWS regions - Dublin, Frankfurt, US East/West, Tokyo
We are ready to provide tests for up to 200 threads for free

For the test, open the form, where we indicate the email, fill in the URL, select the number of testing threads, region and start the test.

*** UPDATE ***
I see a lot of brave Khabra residents setting a task for 200 threads. If we assume that 1 page is rendered in 1 second, then this corresponds to traffic of >100K visitors per hour. Ordinary projects, including ours, die from such tests.

In a minute, your result will be ready (for an example, see the excellent result - testing example.net). As you can see, 200 threads allows you to generate more than 1000 requests per second - it all depends on the speed of communication with the service being tested, etc. actually, the speed of response.

If you are ready to show off your result on our website, you can click the Public result button. To show it to your colleagues, just send a link.

What to test?
Static resources, images, scripts must be served from a CDN. It makes no sense to test their upload speed IMHO; you only need to test the overall page loading speed, for example using the good old http://tools.pingdom.com/fpt/

Loadme focuses on testing page code / api methods, etc... Of course, it is possible to test nginx serving 1x1.gif using this tool, but there is no practical benefit, and nginx will not even warm up from this.

To determine which pages are the bottleneck, it is best to use newrelic. Unlike the popular google analytics, it also allows you to track the statistics of bot requests, and build queries based on the number of operations per page, as well as which page most spoiled the user experience according to the apdex index.
As you know, a fly in the ointment spoils a barrel of honey, and if your application slows down on some even relatively rare actions, this may well affect popular lightweight operations.

How do redirects work?
Redirects are executed; We actively use them to test one of our sites, wikiart.org, by implementing the “go to a random picture” function on it.

Why is it important to test multiple URLs?
To test the mutual influence of popular fast pages and slow ones (for example, search)

Why is $RND needed?
The syntax is $RND(from,to).
For example, http://someshop.com/search?from=$RND(0,1000)&to=$RND(1000,10000) will generate arbitrary queries to search for products with prices ranging from 0 to 1000 and ending from 1000 to 10000. This makes it possible to estimate the real search power.
For example, the popular Ukrainian store Rozetka spends an average of 5 seconds searching for smartphones at a random price:
http://loadme.socialtalents.com/Result/ViewById/56108a645b5f1700481cc21d, which is a very far from ideal result.
Amazon copes with this task fundamentally better - a significant number of errors as a result are most likely ddos protection

Future plans

Post, put, delete requests
The necessary thing is definitely in the plans.

Authorization
Will cookie support be enough so that the first request logs the test under a random user (which will require support from the server), and further work will take place on behalf of this user?

Step tests
Let's say, run a series of tests: 25%, 50%, 75% and 100%, and see the difference in speed.

Instead of the number of threads, let the user choose how many operations per second he wants to initiate.

Regular scheduled test
Repeat the test every day/week and send a report by email.
You can also provide some kind of webhook to trigger an existing test from code (for example, after an update)

Improved throughput visualization
The server may have behaved erratically. We plan to add visualization of server throughput by seconds.

Domain ownership confirmation
The limit of no more than 200 agents per domain exists precisely to ensure that no one throws someone else’s website into ddos. You can create another subdomain for your site and test it again.
In the future, however, it will be necessary to verify domains using a CNAME record or a file with a specific name.

Existing competitors

Loadimpact.com - for a normal load test, at least 100 requests per second, 1500 so-called “virtual users” will be required - each of them loads the page once every 15 seconds. This package currently costs $299 per month.

Loader.io is an excellent service, the paid package is only $99 per month. Very flexible URL settings - you can set methods, cookies, headers, but we didn’t have enough test randomization.

When a web application (site, service) is still quite young, but aimed at a wide audience, it is very difficult to understand how powerful server hardware is required. So the best solution would be to simulate user flow using synthetic tests.

Apache Bench

Probably one of the easiest to use and popular tests for checking the load on a website. The utility is suitable for both simple and advanced testing:

Ab -c 50 -n 10000 -f TLS1.2 -H "Accept-Encoding: gzip,deflate" https://somesite.com/

# Check the maximum number of requests with TLS

The team executed 10,000 requests in 50 threads and, among other things, showed the speed and number of requests processed:

Total transferred: 59560000 bytes HTML transferred: 52160000 bytes Requests per second: 816.77 [#/sec] (mean) Time per request: 122.434 (mean) Time per request: 2.449 (mean, across all concurrent requests) Transfer rate: 2375.33 received

# The test log provides much more information

From this report, the most important data will be:

Requests per second- number of requests per second. For example, if a page consists of 20 parts (CSS, images and HTML), then in our example the server is capable of processing about 40 simultaneous users per second.
Time per request (mean)- average time to execute a group of parallel requests (in our case 50);
Time per request (mean, across all concurrent requests)- average time to complete one request.

AB is useful for quickly and roughly assessing the performance of a web server, so if you need to get data closer to reality, you will have to use additional utilities.

Httperf

This open source benchmark was developed by HP to measure web server performance. The tool has not been updated for several years, but is still very relevant.

The utility, like ab, is easy to use and has quite a wide range of functionality. It is launched as simply as ab:

Httperf --hog --server 192.168.122.10 --wsess=100000,5,2 --rate 1000 --timeout 5

# Create 100,000 sessions (5 calls every 2 s) at a speed of 1000

And the log will look like this:

Total: connections 117557 requests 219121 replies 116697 test-duration 111.423 s Connection rate: 1055.0 conn/s (0.9 ms/conn,<=1022 concurrent connections) Connection time : min 0.3 avg 865.9 max 7912.5 median 459.5 stddev 993.1 Connection time : connect 31.1 Connection length : 1.000 Request rate: 1966.6 req/s (0.5 ms/req) Request size [B]: 91.0 Reply rate : min 59.4 avg 1060.3 max 1639.7 stddev 475.2 (22 samples) Reply time : response 56.3 transfer 0.0 Reply size [B]: header 267.0 content 18.0 footer 0.0 (total 285.0) Reply status: 1xx=0 2xx=116697 3xx=0 4xx=0 5xx=0 CPU time [s]: user 9.68 system 101.72 (user 8.7% system 91.3% total 100.0%) Net I/O: 467.5 KB/s (3.8*10^6 bps)

# Among other things, performance is shown by the Request rate

This report should focus on:

Connection rate- real speed of creating new connections. It shows the server’s ability to process connections, that is, in our case, up to 1055 connections/s, but no more than 1022 simultaneous connections.
Connection time- lifetime of successful connections between initialization and closure. Again, it shows the server's performance when processing a large number of connections.
Request rate- speed of processing requests. That is, the number of requests that the server is capable of performing per second shows the responsiveness of the web application.

But for a deeper check and a significant load, you will have to use even more advanced tools.

Tsung

It is a powerful, advanced, multi-tasking and multi-threaded utility. The tool can be used to load HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and Jabber/XMPP servers. Supports SSL, monitoring of system resources and SNMP, Munin or Erlang agents on remote servers, simulation of user behavior and advanced reporting.

The tool is written in Erlang, so first you need to install the necessary repositories, and then download and install Tsung:

Wget http://tsung.erlang-projects.org/dist/tsung-1.6.0.tar.gz tar zxfv tsung-1.6.0.tar.gz cd tsung-1.6.0 ./configure && make && make install

# Unpacking and compiling the utility

All tool settings must be specified in its configuration file:

Cp /usr/share/doc/tsung/examples/http_simple.xml /root/.tsung/tsung.xml

# Copying the configuration file template to the Tsung directory

After which you need to edit it by setting the necessary parameters:

# You can specify additional options (for example, user browsers), multiple nodes for simulating users

Now you can run tsung:

Tsung -f tsung.xml start Starting Tsung "Log directory is: /root/.tsung/log/20160428-1117"

# To run from multiple nodes, they must first be specified in the settings

When the utility has finished its work, you can view the report:

Mkdir report_output cd report_output /usr/lib/tsung/bin/tsung_stats.pl --stats /root/.tsung/log/20160428-1117/tsung.log chromium graph.html

# Specifies the preferred browser

The report will consist of graphs and important additional information. It is worth paying attention to:

Session- the total number of users and the number of simultaneous sessions per second that the web server processed.
Request- web server response time, its ability and speed of processing simultaneous requests. For example, 200 requests/s means that on average 10 users can simultaneously access a web page consisting of a total of 20 components (CSS, images and HTML). And this is more than 400,000 visitors in 12 hours.
Connect- the time required to connect, that is, the responsiveness of the web server.

Additional graphs will allow you to evaluate the load on the web server over the entire testing period, track errors and dynamics.

Other utilities

Of course, the list of tools for checking web server performance and testing site load is not limited to those given in this material. There are a huge number of such utilities, both paid and free. There are sites for generating loads, such as LoadImpact, utilities for running from the command line, and full-fledged programs with a GUI. One of the most popular with a user interface, by the way, is Apache JMeter - powerful, advanced and quite complex.

The most important

Apache Bench, Httperf and Tsung are great for load testing on sites large and small. But only tsung will be able to squeeze all the juice out of a web server and show what it is capable of in conditions close to reality. Do not forget that all tests must first be carried out for one user in order to trace the dependence and have a reference point.

Maybe someone will be interested in how to “quickly” conduct load testing of their web application.
Details under the cut

Instead of a preface

At today's stand-up, Marek (a programmer from Poland taking part in the EmForge project) said that he talked with a number of friends who in the past had a lot of experience working with Liferay (which we actively use) - and the experience turned out to be very negative, first of all due to speed problems. Some projects were stupidly abandoned due to the fact that these problems could not be solved.

No - we, of course, were going to carry out load testing, but not now, a little later, when there will be more functionality, and then purely to make sure that everything is ok, or “not ok” in some certain places - and to correct them.
But here the question arose: if everything is so bad, then some decisions must be made now - before it is too late. There is only one conclusion - load testing receives a higher priority compared to other tasks

Not "quickly"

Initially, it was planned to go the standard route - take JMeter, write a simple script for crawling the main pages with the main functionality by an anonymous user - then improve it little by little, while simultaneously solving the issues of how to competently run this stuff on several client machines.

In general, the task is not for one hour

How about a quick one?

But then I remembered that there was an article on Habr (unfortunately I couldn’t find the article - I would have posted the link), where a person complained that people don’t run load testing on their website, they send a link to Habr, and then, when they need to skim off the “cream” "It's painful to get the site up from Habraeffect (and users see nothing but error messages).
So, someone there recommended several services that conduct such load testing.

In general, the most useful link on the topic of load testing turned out to be this one - both utilities such as JMeter and services for organizing testing are listed here. I’ll dwell on the first three in a little more detail.

Very quickly?

To put it very quickly, this is Load Impact - no registration required - go in - give the URL - and within 10-15 minutes 50 virtual users are terrorizing your page. Stupid, simple - but at least it will allow you to see that at the first influx your application will not fail. Didn't go to bed? Go ahead

Load testing in 1.5 hours

I really liked LoadStorm. Work with it is structured as follows:
1. register
2. Create a test - which indicates the site that we will torture
3. Before you start the torture, verification is required (what if you want to install a competitor’s website????). you need to put a certain text with a code on the main page - or a file with a certain name in the root
4. Next, we create a scenario - when creating a scenario, we describe how the user navigates your site, what links he clicks, you can submit forms. Everything is quite intuitive and clear
5. then we say when to launch
6. At the appointed time, the test starts, wait 30 minutes until up to 50 users wander around your site according to your instructions - and we receive a report.

Yes, 50 simultaneous users is not entirely serious - it’s not even close to the habro effect - but it’s something. If you need more, there is a paid subscription (yes, I forgot to say that it’s all free). In my case, 50 simultaneous users is a load that I can’t even dream of in the next few months - so that was enough for me.

In general, it took about an hour and a half to describe a scenario of 15 consecutive pages, wait for the test to run and wait for the results themselves, as a result I received graphs like

This graph shows how the system was tormented - in my case there were a maximum of 47 users - and a little more than 3 requests per second
Well, the most interesting

From which it follows that if we exclude the maximum peak of 5 seconds (at this moment Garbage Collector decided to turn on) - otherwise the application behaved well - and regardless of the number of users - that is, a load of 50 users does not load the site - there is also stock is good.

It is clear that such testing is not entirely “serious” in terms of the results produced, and 50 simultaneous users cannot be called a serious load, but considering the time spent (an hour and a half) and the money (0 rubles), the result is quite adequate. At least we are convinced that if there are any problems with performance, we still won’t see it in the coming months

A little longer and more expensive

If you want something a little more serious, you can try it