Тестирование масштабируемости
Тестирование масштабируемости — это тестирование программного приложения для измерения его способности масштабироваться или масштабироваться с точки зрения любых его нефункциональных возможностей.
Тестирование производительности , масштабируемости и надежности обычно группируется аналитиками качества программного обеспечения .
Основные цели тестирования масштабируемости — определить лимит пользователей для веб-приложения и гарантировать , что качество работы конечного пользователя при высокой нагрузке не будет нарушено. Одним из примеров является возможность своевременного доступа к веб-странице с ограниченной задержкой ответа. Другая цель — проверить, справится ли сервер , т.е. выйдет ли сервер из строя, если он будет находиться под большой нагрузкой? [1]
В зависимости от тестируемого приложения проверяются разные параметры. Если веб-страница тестируется, будет протестировано максимально возможное количество одновременных пользователей. [2] От тестируемого приложения также зависят тестируемые атрибуты — они могут включать загрузку ЦП , использование сети или взаимодействие с пользователем.
Успешное тестирование позволит выявить большинство проблем, которые могут быть связаны с сетью, базой данных или аппаратным/программным обеспечением. [3]
Создание теста масштабируемости
[ редактировать ]При создании нового приложения сложно точно спрогнозировать количество пользователей через 1, 2 или даже 5 лет. Хотя можно сделать приблизительную оценку, это не точная цифра. Проблема с увеличением числа пользователей заключается в том, что это может создать новые области сбоев. Например, если у вас 100 000 новых посетителей, проблема может быть не только в доступе к приложению; у вас также могут возникнуть проблемы с базой данных, в которой вам необходимо хранить все данные этих новых клиентов. [4]
Увеличение нагрузки
[ редактировать ]Вот почему при создании теста масштабируемости важно постепенно увеличивать масштаб. Эти этапы можно разделить на малые, средние и высокие нагрузки.
Мы должны расширять масштабы постепенно, поскольку на каждом этапе тестируются разные аспекты. Небольшие нагрузки обеспечивают функционирование системы должным образом на базовом уровне. Средние нагрузки проверяют, может ли система функционировать на ожидаемом уровне. Высокие нагрузки проверяют способность системы справиться с высокой нагрузкой. [5]
Тестовая среда
[ редактировать ]Среда должна быть постоянной на протяжении всего тестирования, чтобы обеспечить точные и надежные результаты. Если тестирование пройдет успешно, мы должны увидеть пропорциональное изменение производительности. Например, если мы удвоим количество пользователей в системе, мы должны увидеть падение производительности на 50%. [6]
В качестве альтернативы, при измерении статистики системы, такой как использование памяти или ЦП, с течением времени, это может иметь другой график, который не является пропорциональным, поскольку пользователи не отображаются ни на одной из осей.
Результаты тестирования масштабируемости
[ редактировать ]
После сбора данных со всех этапов мы можем приступить к построению результатов с использованием различных графиков, адаптированных к конкретным анализируемым переменным и показателям. Тип выбранных графиков будет зависеть от характера данных и целей анализа.
Непропорциональный результат
[ редактировать ]На рисунке 1 мы видим график, показывающий использование ресурсов (в данном случае памяти) с течением времени. График не является пропорциональным, но его все же можно считать пройденным тестом, поскольку изначально существует фаза наращивания мощности, когда система начинает работать, однако по мере добавления большего количества пользователей использование памяти практически не меняется. [7] Это означает, что текущий объем памяти сможет справиться со всеми 3 этапами теста.
Пропорциональный результат
[ редактировать ]
На рисунке 2 мы видим более пропорциональное увеличение, сравнивая количество пользователей со временем, затраченным на выполнение отчета. При низкой нагрузке в 20 пользователей среднее время составляет 5,5 секунд, при увеличении нагрузки до средней (40 пользователей) и высокой нагрузки (60 пользователей) среднее время увеличивается до 9,5 и 18 секунд соответственно. [6]
В некоторых случаях могут потребоваться изменения в программном или аппаратном обеспечении сервера. После того как необходимые обновления будут выполнены, мы должны повторно запустить тесты, чтобы убедиться, что обновления эффективно решают ранее возникшие проблемы. [8]
Когда мы имеем пропорциональный результат, нет узких мест по мере масштабирования и увеличения нагрузки на систему. [9]
Вертикальное и горизонтальное масштабирование
[ редактировать ]В результате тестирования масштабируемости могут потребоваться обновления программного и аппаратного обеспечения. Эти обновления можно разделить на вертикальное или горизонтальное масштабирование.
Вертикальное масштабирование, также известное как масштабирование, представляет собой процесс замены компонента устройством, которое обычно является более мощным или улучшенным. Например, замена процессора на более быстрый. Горизонтальное масштабирование, также известное как горизонтальное масштабирование, подразумевает настройку другого сервера, например, для работы параллельно с исходным, чтобы они разделяли рабочую нагрузку. [10]
Преимущества и недостатки
[ редактировать ]Оба метода масштабирования имеют свои преимущества и недостатки. Хотя масштабирование может оказаться проще, добавление аппаратных ресурсов может привести к снижению отдачи . [11] Это означает, что каждый раз, например, обновляя процессор, мы не всегда получаем тот же уровень преимуществ, что и предыдущее изменение.
Однако горизонтальное масштабирование может оказаться чрезвычайно дорогостоящим, и это касается не только стоимости целых систем, таких как серверы, но мы также должны учитывать затраты на их регулярное обслуживание. [11]
Ссылки
[ редактировать ]- ^ «Планирование нагрузочного тестирования» . docs.oracle.com . Проверено 23 октября 2015 г.
- ^ «Тестирование масштабируемости» . Блог производительности . Проверено 25 октября 2015 г.
- ^ Джоши, Пратик. «Зачем нам нужно тестирование производительности?» . Вечная загадка . Проверено 25 октября 2015 г.
- ^ «Обнаружение правильных метрик для тестирования масштабируемости» . www.theserverside.com . Проверено 25 октября 2015 г.
- ^ «Цитовский», «Бернардини», «Мацей», «Маттео» (2013). «Практический анализ масштабируемости» (PDF) . Партнерство в области передовых вычислений в Европе .
- ^ Jump up to: а б «Проверенные практики IBM Cognos: разработка успешного теста производительности и масштабируемости для IBM Cognos BI» . www.ibm.com . 17 ноября 2011 г. Проверено 25 октября 2015 г.
- ^ «Производительность предприятия и результаты испытаний» (PDF) . Серена . 2011.
- ^ «Тестирование масштабируемости: проверка возможности расширения производительности сайта» . support.smartbear.com . Проверено 28 октября 2015 г.
- ^ «Технический блог Netflix: Сравнительный анализ масштабируемости Cassandra на AWS: более миллиона операций записи в секунду» . techblog.netflix.com . Проверено 4 ноября 2015 г.
- ^ Бонди, Андре (2014). Основы проектирования производительности программного обеспечения и систем: процесс, моделирование производительности, требования, тестирование, масштабируемость и практика. Раздел 11.2 . ISBN 0321833821 .
- ^ Jump up to: а б «Тестирование масштабируемости» (PDF) . Комп Нус Образование .