Меню Закрыть

Проверка сайта на нагрузку

Содержание

Cервис для анализа отказоустойчивости сайта и сервера и мониторинга доступности сайта

Зарегистрируйтесь и делайте бесплатные проверки до 100 посетителей онлайн!

Нагрузочное тестирование сайтов и серверов

Для чего нужно нагрузочное тестирование сайта? Нагрузка на хостинг или сервер от Вашего сайта постоянно растет и может оказаться критичной для работы сайта. Наша система нагрузочного тестирования позволяет определить, как ведет себя сайт под нагрузкой при помощи комплексного стресс тест сайта! Если во время нагрузочного тестирования сервер справляется со всеми оказавшимися на сайте посетителями, Вы можете быть уверены в том, что ваш сайт будет доступен для реальных посетителей под любой нагрузкой. Проверить нагрузку на сайт очень просто, достаточно ввести адрес вашего сайта и количество желаемых одновременных посетителей.

Мониторинг доступности сайта

Успешное прохождение нагрузочного тестирования сервером не единственное условие того, что сайт будет доступен для пользователей. Постоянный мониторинг доступности сайта позволяет предотвратить возможные проблемы недоступности и своевременно реагировать на них. Около 80% людей не знают, что их сайты бывают недоступны по различным причинам, о которых они также не подозревают. В нашем сервисе помимо бесплатного мониторинга и проверки доступности сайта, Вы также можете проверить скорость загрузки сайта.

Когда веб-приложение (сайт, сервис) еще достаточно молодое, но нацелено на широкую аудиторию, то весьма сложно понять насколько мощное серверное оборудование требуется. Так что лучшим решением будет симуляция потока пользователей при помощи синтетических тестов.

Apache Bench

Наверное, один из самых простых в использовании и популярных тестов для проверки нагрузки на сайт. Утилита подходит как для простого, так и продвинутого тестирования:

# Проверка максимального количества запросов с TLS

Команда выполнила 10 000 запросов в 50 потоков и, кроме всего прочего, показала скорость и обработанное количество запросов:

# Лог теста выдает намного больше информации

Из этого отчета самыми важными данными будут:

  • Requests per second — количество запросов в секунду. К примеру если страница состоит из 20 частей (CSS, картинки и HTML), то в нашем примере сервер способен обработать около 40 одновременных пользователей в секунду.
  • Time per request (mean) — среднее время на выполнение группы параллельных запросов (в нашем случае 50);
  • Time per request (mean, across all concurrent requests) — среднее время на выполнение одного запроса.

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

Читайте также:  Телефон lg раскладушка фото

Httperf

Этот тест с открытым исходным кодом был разработан в HP для измерения производительности веб-сервера. Инструмент не обновлялся несколько лет, но все еще является весьма актуальным.

Утилита, как и ab, проста в использовании и обладает достаточно широким функционалом. Запускается она так же просто, как и ab:

# Создание 100 000 сессий (по 5 вызовов через каждые 2 с) со скоростью 1000

А лог будет выглядеть так:

# Кроме всего прочего, производительность показывает величина скорости запросов (Request rate)

В этом отчете стоит сфокусироваться на:

  • Connection rate — реальная скорость создания новых соединений. Она показывает способность сервера обрабатывать соединения, то есть в нашем случае до 1055 соед./с, но не более 1022 одновременных соединений.
  • Connection time [ms] — время “жизни” успешных соединений между инициализацией и закрытием. Опять же показывает производительность сервера при обработке большого количества соединений.
  • Request rate — скорость обработки запросов. То есть, количество запросов, которые сервер способен выполнять за секунду, показывает отзывчивость веб-приложения.

Но для более глубокой проверки и существенной нагрузки придется использовать еще более продвинутые инструменты.

Tsung

Это мощная, продвинутая, мультизадачная и мультипоточная утилита. Инструмент может использоваться для нагрузки серверов HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP и Jabber/XMPP. Поддерживается SSL, мониторинг ресурсов системы и агенты SNMP, Munin или Erlang на удаленных серверах, симуляция поведения юзеров и расширенные отчеты.

Инструмент написан на Erlang, так что для начала необходимо установить нужные репозитории, а затем скачать и установить Tsung:

# Распаковка и компиляция утилиты

Все настройки инструмента необходимо прописать в его файле конфигурации:

# Копирование шаблона файла конфигурации в директорию Tsung

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

# Можно указывать дополнительные опции (к примеру браузеры юзеров), множества нодов для симуляции пользователей

Теперь можно запускать tsung:

# Для запуска с множества нодов их нужно предварительно указать в настройках

Когда утилита закончила свою работу, можно просмотреть отчет:

# Указывается предпочтительный браузер

Отчет будет состоять из графиков и важной дополнительной информации. В нем стоит обратить внимание на:

  • Session — общее количество пользователей и количество одновременных сессий в секунду, которые веб-сервер обработал.
  • Request — время отклика веб-сервера, его способность и скорость обработки одновременных запросов. К примеру 200 запросов/с значит, что в среднем 10 пользователей сможет одновременно получить зайти на веб-страницу, состоящую в общем из 20 компонентов (CSS, картинки и HTML). А это более 400 000 посетителей за 12 часов.
  • Connect — время, требуемое на подключение, то есть отзывчивость веб-сервера.
Читайте также:  Как подключить ноутбук к телевизору через кабель

Дополнительные графики позволят оценить нагрузку на веб-сервер за все время тестирования, отследить возникшие ошибки и динамику.

Другие утилиты

Конечно же список инструментов для проверки производительности веб-сервера и тестирования нагрузки на сайт не ограничивается приведенным в этом материале. Таких утилит огромное множество, как платных, так и бесплатных. Существуют сайты для генерации нагрузки, типа LoadImpact, утилиты для запуска из командной строки и полноценные программы с GUI. Одной из самых популярных с пользовательским интерфейсом, кстати, является Apache JMeter — мощная, продвинутая и достаточно сложная.

Самое главное

Apache Bench, Httperf и Tsung отлично подходят для тестирования нагрузки на большие и маленькие сайты. Но только tsung сможет выжать все соки из веб-сервера и показать на что он способен в условиях, приближенных к реальности. Не забывайте, что сначала все тесты нужно провести для одного пользователя, чтобы проследить зависимость и иметь точку отсчета.

Примеры тестирования оборудования сервера под нагрузками.

Проверка работы Mysql под нагрузкой Sysbench

Децентрализованный мониторинг серверов

Худшие практики при работе над растущими проектами

Быстрая генерация данных для MySQL таблиц

Основные понятия о шардинге и репликации

Архитектурные принципы высоконагруженных приложений

Как строятся по-настоящему большие системы на основе MySQL

Как и зачем используются очередей сообщений

Правила и практика масштабирования Твиттера

Как решать типичные задачи с помощью NoSQL

Что значит высокая нагрузка (highload) и что при этом делать?

3 аспекта эффективного мониторинга для Web приложений

Разделение базы данных на несколько независимых баз

Типы и способы применения репликации на примере MySQL

Методы улучшения производительности веб-приложения для высоконагруженных проектов на Django

Простые и быстрые варианты переноса ключей Redis на другой сервер.

Эффективный механизм записи данных из Nginx’a прямо в Clickhouse минуя промежуточные узлы

Ускорение PHP приложений на платформе YII в несколько раз

Тестирование запросов онлайн с помощью hurl.it

Настройка Master-Master репликации на MySQL за 6 шагов

Примеры ad-hoc запросов и технологии для их исполнения

Если хочется просто и быстро, то вполне сгодится Apache Benchmark идущий в комплекте с веб-сервером Apache. Как-то так:

ab -n 1000 -c 10 "http://my.site.dot.com/url/path/"

Варьируя число одновременных соединений (-c 10) и общее количество запросов (-n 1000) можно примерно прикинуть когда сайт начнёт загибаться. Тестировать лучше с другой машины. Также стоит учесть, что если контент страницы меняется от запроса к запросу (динамика), то AB посчитает такие ответы сервера как Failed: www.celebrazio.net/tech/unix/apache_bench.html

Читайте также:  Как поместить картинку на рабочий стол

Начать тестирование лучше с наиболее часто посещаемых страниц исходя из аналитики сайта, а также ориентируясь на своё понимание его структуры (если сайт самописный, то вы должны прекрасно представлять его слабые в плане производительности разделы).

Если захочется большего — смотрите более богатые по возможностям Apache JMeter или Tsung (первый графический, второй консольный). Оба умеют кластеризоваться и генерировать нагрузку с нескольких машин (для этого удобно арендовать инстансы в Amazon EC2), имеют встроенный прокси для записи пользовательских сессий и позволяют задать скорость клиентского соединения (актуально для имитации медленных клиентов и оценки влияния того же nginx).

В любом случае, перед тем как измерять производительность сайта, озаботьтесь мониторингом серверов на которых этот сайт крутится. Без этого смысла в бенчмарках очень мало — они дадут вам какие-то цифры, но дальнейшего плана действий у вас не будет. Как минимум — запустите на машинах утилиту top и смотрите загрузку CPU, потребление памяти и дисковую активность. Также после тестирования просматривайте логи на предмет появившихся ошибок (нехватку сокетов, памяти, ошибки веб-сервера или БД). Полезно включить логгирование медленных запросов в MySQL.

Дальше — устраняйте выявленные узкие места и повторяйте процесс заново, до тех пор пока не выйдете на приемлемый уровень производительности.

loadimpact.com/ позволяет загрузить сайт (запросы, трафик).

На реальном проекте роботы могут повлиять на работу сайта, т.к. запрашивают непопулярные страницы, которые, скорее всего, не закешированы (или кеш устарел). Поэтому можно попробовать поставить загрузку всего сайта (wget) и одновременно проверять скорость отдачи (ab или loadimpact).

Если это не помогло завалить сайт, попробуйте заказать небольшой DDoS (GET- и POST-запросами).

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

А из тулзов всем известный ab (Apache Benchmark). Еще очень интересен inject от создателя haproxy. В нем можно задавать сценарии поведения пользователей.

Рекомендуем к прочтению

Добавить комментарий

Ваш адрес email не будет опубликован.