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

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

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

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

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

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

Следующее: Как балансировать краткость и абстракцию