# Как проводить стресс-тестирование

Стресс-тестирование это увлекательная вещь. Сначала кажется, что его цель - выяснить, будет ли система работать под нагрузкой. В действительности, обычно система работает под нагрузкой, но начинает отказывать в каких-то местах, если нагрузка достаточно большая. Я называю это "достичь потолка". Могут быть исключения, но почти всегда это "потолок". Смысл стресс-тестирования в том, чтобы выяснить, где находится этот потолок для системы, а потом понять, как его отодвинуть.

План для стресс-тестирования следует разрабатывать на ранних стадиях проекта, так как часто он помогает в точности прояснить, что именно ожидается от системы. Две секунды на запрос веб-страницы это позорный провал или оглушительный успех? Достаточно ли 500 одновременных пользователей? Ответы зависят от системы, но перед началом ее проектирования их уже стоит знать. Чтобы быть полезным, стресс-тестирование должно достаточно хорошо имитировать действительную нагрузку. Вряд ли возможно смоделировать 500 одновременных хаотичных и непредсказуемых пользователей, используя многопоточность системы, но как минимум можно создать 500 симуляций и попытаться смоделировать некоторую часть того, что будут делать реальные пользователи.

Во время стресс-тестирования начните с небольшой нагрузки и увеличивайте ее по одному параметру системы, например, по частоте входных запросов или по величине входных данных, пока вы не достигнете потолка системы. Если вы достигли его слишком рано, чтобы удовлетворить требованиям к системе, выясните, какой ресурс является узким местом в системе (как правило, сильно не хватает чего-то одного). Что это: память, процессор, операции чтения и записи, пропускная способность сети или задержка данных? Затем выясните, как вы можете отодвинуть потолок. Обратите внимание, что повышение потолка или увеличение нагрузки, с которой справляется система, может не помочь или даже снизить производительность для легконагруженной системы. Обычно производительность под большой нагрузкой важнее производительности под маленькой.

Возможно, вам придется получить представление о нескольких разных параметрах системы, чтобы построить ее мысленную модель. Здесь не обойтись какой-то одной техникой. Например, логирование часто дает хорошую картину о реальном времени на исполнение команд между двумя событиями в системе, но если оно внедрено небрежно, то не дает понимания об использовании памяти или даже о размере структур данных. Аналогично, в современных системах могут взаимодействовать несколько компьютеров и множество программных систем. Когда вы упираетесь в потолок (то есть производительность нелинейно зависит от размера входных данных), эти сторонние программы могут оказаться узким местом. Представление о работе этих программ, даже в виде простого измерения загрузки процессоров на всех задействованных машинах, может оказаться очень полезным.

Знать потолок системы важно не только для того, чтобы отодвинуть его, но и для обеспечения предсказуемости, чтобы эффективно управлять связанными с системой бизнес-процессами.

Следующее: [Как балансировать краткость и абстракцию](/how-to-be-a-programmer/ru/2-intermediate/personal-skills/05-how-to-balance-brevity-and-abstraction.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://braydie.gitbook.io/how-to-be-a-programmer/ru/2-intermediate/personal-skills/04-how-to-stress-test.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.