Тестирование масштабируемости - Scalability testing

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

Спектакль, масштабируемость и надежность тесты обычно группируются по аналитики качества программного обеспечения.

Основные цели тестирования масштабируемости - определить лимит пользователей для веб-приложения и обеспечить его завершение. Пользовательский опыт при высокой нагрузке не нарушается. Одним из примеров является возможность своевременного доступа к веб-странице с ограниченной задержкой ответа. Другая цель - проверить, не сервер может справиться, т.е. выйдет из строя сервер при большой нагрузке? [1]

В зависимости от тестируемого приложения тестируются разные параметры. Если веб-страница тестируется, будет проверено максимально возможное количество одновременных пользователей.[2] Также от тестируемого приложения зависят тестируемые атрибуты - они могут включать ЦПУ использование, использование сети или пользовательский опыт.

Успешное тестирование выявит большинство проблем, которые могут быть связаны с сетью, базой данных или аппаратным / программным обеспечением.[3]

Создание теста масштабируемости

При создании нового приложения сложно точно предсказать количество пользователей через 1, 2 или даже 5 лет. Хотя оценка может быть сделана, это не точное число. Проблема с увеличением числа пользователей заключается в том, что это может создавать новые области отказа. Например, если у вас 100 000 новых посетителей, проблема может быть не только в доступе к приложению; у вас также могут возникнуть проблемы с базой данных, в которой вам нужно хранить все данные этих новых клиентов.[4]

Увеличение нагрузки

Вот почему при создании теста масштабируемости важно постепенно увеличивать масштаб. Эти шаги можно разделить на небольшие, средние и высокие нагрузки.[5]

Мы должны постепенно увеличивать масштаб, поскольку на каждом этапе тестируется отдельный аспект. Небольшие нагрузки обеспечивают нормальную работу системы на базовом уровне. Средние нагрузки проверяют, может ли система функционировать на ожидаемом уровне. Тестирование высоких нагрузок: система может выдерживать высокие нагрузки.[6]

Тестовая среда

Окружающая среда должна быть постоянной на протяжении всего тестирования, чтобы обеспечить точные и надежные результаты. Если тестирование прошло успешно, мы должны увидеть пропорциональное изменение производительности. Например, если мы удвоим количество пользователей в системе, мы увидим падение производительности на 50%.[7]

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

Результаты тестирования масштабируемости

Рисунок 1. График показывает использование ресурсов (памяти) во времени.

После того, как мы собрали данные с разных этапов, мы можем начать отображать результаты на различных графиках, чтобы показать результаты. Однако графики могут отличаться в зависимости от того, что строится.

Непропорциональный результат

На рисунке 1 мы можем видеть график, показывающий использование ресурсов (в данном случае памяти) во времени. График не является пропорциональным, но все же может считаться пройденным тестом, так как изначально существует фаза наращивания, когда система начинает работать, однако по мере добавления новых пользователей использование памяти мало меняется.[8] Это означает, что текущий объем памяти может выдержать все 3 этапа теста.

Пропорциональный исход

Рисунок 2. На этом графике показано среднее время, затрачиваемое на выполнение отчета, в зависимости от количества пользователей.

На рисунке 2 мы можем увидеть более пропорциональный рост, сравнивая количество пользователей со временем, затраченным на выполнение отчета. При низкой загрузке в 20 пользователей среднее время составляет 5,5 секунды, при увеличении нагрузки до средней (40 пользователей) и высокой нагрузки (60 пользователей) среднее время увеличивается до 9,5 и 18 секунд соответственно.[7]

В некоторых случаях могут потребоваться изменения в программном или аппаратном обеспечении сервера. После того, как необходимые обновления будут выполнены, мы должны повторно запустить тесты, чтобы убедиться, что обновления были эффективными при решении ранее поднятых проблем.[9]

Когда у нас есть пропорциональный результат, узких мест не возникает, поскольку мы увеличиваем масштаб и увеличиваем нагрузку на систему. [10]

Вертикальное и горизонтальное масштабирование

В результате тестирования масштабируемости могут потребоваться обновления программного и аппаратного обеспечения. Эти обновления можно разделить на вертикальное или горизонтальное масштабирование.

Вертикальное масштабирование, также известное как масштабирование, представляет собой процесс замены компонента устройством, которое, как правило, является более мощным или улучшенным. Например, замена процессора на более быстрый. Горизонтальное масштабирование, также известное как масштабирование, заключается в настройке другого сервера, например, для работы параллельно с исходным, чтобы они разделяли рабочую нагрузку.[11]

Преимущества и недостатки

У обоих методов масштабирования есть свои преимущества и недостатки. Хотя масштабирование может быть проще, добавление аппаратных ресурсов может привести к убывающая отдача.[12] Это означает, что каждый раз, когда мы, например, обновляем процессор, мы не всегда получаем тот же уровень преимуществ, что и предыдущее изменение.

Однако горизонтальное масштабирование может быть чрезвычайно дорогостоящим, не только из-за стоимости целых систем, таких как серверы, но мы также должны учитывать их регулярные расходы на обслуживание.[12]

Рекомендации

  1. ^ «Планирование нагрузочного тестирования». docs.oracle.com. Получено 2015-10-23.
  2. ^ «Тестирование масштабируемости». Блог производительности. Получено 2015-10-25.
  3. ^ Джоши, Пратик. «Зачем нам нужно тестирование производительности?». Вечная загадка. Получено 2015-10-25.
  4. ^ «Обнаружение правильных показателей для тестирования масштабируемости». www.theserverside.com. Получено 2015-10-25.
  5. ^ «МАСШТАБИРОВАНИЕ ПРОТИВ МАСШТАБИРОВАНИЯ В СРЕДЕ QLIKVIEW». 2012.
  6. ^ «Цитовский», «Бернардини», «Мацей», «Маттео» (2013). «Анализ масштабируемости Prac» (PDF). Партнерство для передовых вычислений в Европе.
  7. ^ а б «Проверенные методы IBM Cognos: разработка успешного теста производительности и масштабируемости для IBM Cognos BI». www.ibm.com. 2011-11-17. Получено 2015-10-25.
  8. ^ «Производительность предприятия и результаты тестирования» (PDF). Серена. 2011.
  9. ^ «Тестирование масштабируемости: проверка возможности увеличения производительности сайта». support.smartbear.com. Получено 2015-10-28.
  10. ^ «Технический блог Netflix: сравнительный анализ масштабируемости Cassandra на AWS - более миллиона операций записи в секунду». techblog.netflix.com. Получено 2015-11-04.
  11. ^ Бонди, Андре (2014). Основы проектирования производительности программного обеспечения и систем: процесс, моделирование производительности, требования, тестирование, масштабируемость и практика. Раздел 11.2. ISBN  0321833821.
  12. ^ а б «Тестирование масштабируемости» (PDF). Comp Nus Education.

внешняя ссылка