Test web server linux

Анализ нагрузки на веб-сервер Linux

В данной статье пойдет речь о мониторинге нагрузки, именно, в контексте веб-сервера. Мы не будем особо заострять внимание на проверке производительности системы, как, например, командами top, htop, free и так далее.

Нагрузка на сервер

Анализ нагрузки стоит начать с общих метрик — потребление процессорного времени, памяти, нагрузки на сеть и дисковую систему.

Нагрузка по процессам

Проверить, нагружен ли сервер, а также понять, какой именно процесс больше всего потребляет ресурсов можно с помощью команд:

* по сути, все 3 вышеперечисленные команды выдают одну и туже информацию в разном виде. Какой-то из них может оказаться удобнее пользоваться. Утилита top встроена в систему, для использования остальных необходимо установить одноименные пакеты.

Оперативная память

Для определения объема свободной и занимаемой памяти можно воспользоваться командой:

* предыдущие команды тоже показывали утилизацию памяти, но кому-то команда free может показаться нагляднее.

Нагрузка на диск

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

а) На системы Debian / Ubuntu:

apt-get install iotop

б) На системы Red Hat / CentOS:

yum install iotop

После выполняем следующую команду:

Сетевая активность

Для измерения нагрузки на сеть необходимо установить утилиту nload.

а) В CentOS / Red Hat:

yum install nload

б) В Ubuntu / Debian:

apt-get install nload

После установки, запускаем утилиту командой:

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

Что грузит систему

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

Использование lsof

lsof — утилита командной строки, которая отображает какие файлы используются процессами. Она позволит определить, к каким скриптам идет обращение со стороны веб-сервера. Для начала, необходимо установить lsof.

а) В CentOS / Red Hat:

yum install lsof

б) В Ubuntu / Debian:

apt-get install lsof

Теперь можно выполнить следующие команды:

* первая команда покажет, к каким файлам обращается apache, вторая — php-fpm (часто можно увидеть в связке с nginx).

Анализ error-логов

Анализ логов ошибок позволит не только обнаружить проблемы в работе сайта, но и найти причину его медленной работы. По умолчанию, логи находятся в каталоге /var/log. Если мы не меняли расположение логов, запускаем следующие команды:

tail -f /var/log/nginx/error.log

* лог ошибок nginx.

tail -f /var/log/php-fpm/error.log

* лог ошибок php-fpm.

tail -f /var/log/httpd/error_log

* лог ошибок apache в CentOS.

tail -f /var/log/apache2/error_log

* лог ошибок apache в Ubuntu.

В первую очередь, нужно обратить внимание на повторяющиеся ошибки — они могут быть причиной проблем. Лучше всего, добиться полного отсутствия ошибок, внеся исправления в работу сайта. Возможно, это устранит проблемы производительности.

Статистика веб-сервера

Для веб-серверов можно воспользоваться служебной страницей просмотра статуса. Она может показать статистику запросов к веб-серверу.

Apache

Для Apache необходим модуль mod_status, который идет в комплекте с данным веб-сервером. Проверить подключение модуля можно в конфигурационном файле httpd.conf (в разных Linux системах может находится в различных каталогах).

По умолчанию, server-status не активен. Создаем конфигурационный файл.

Для CentOS / Red Hat:

Для Ubuntu / Debian:

* где 2 — используемая версия apache.

В открытый конфигурационный файл добавим:

servername 111.111.111.111

Sethandler server-status

* где 111.111.111.111 — IP-адрес нашего веб-сервера; 80 — порт, на котором слушает apache.
* в данном примере мы прописали два варианта просмотра статистики: первый — обращение в браузере к серверу по IP-адресу + /server-status; второй — обращение к любому сайту + /server-status. Разные способы оправданы для разных настроек самих сайтов и используемых CMS.

Проверим корректность внесенных данных и перезапустим веб-сервер apache:

systemctl restart httpd || systemctl restart apache2

Теперь открываем браузер и вводим название сайта + /server-status, например, http://www.dmosk.ru/server-status. Или обращаемся к серверу по IP-адресу, например, http://111.111.111.111/server-status.

NGINX + PHP-FPM

Открываем конфигурационный файл nginx:

В секцию http добавляем:

.
server <
listen 80;
server_name 111.111.111.111;
location /server-status <
stub_status on;
>
>
.

* где 111.111.111.111 — IP-адрес нашего веб-сервера.

Проверяем корректность настройки и перезапускаем nginx:

systemctl restart nginx

Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:

Теперь настроим статистику для php-fpm. В конфигурационном файле nginx в нашу директиву server добавим:

.
server <
listen 80;
server_name 78.110.63.31;
location /server-status <
stub_status on;
>
location /status <
access_log off;
include fastcgi_params;
#fastcgi_pass unix:/var/run/php-fpm/php5-fpm.sock;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>
>
.

* обратите внимание на закомментированную строку и строку под ней. В зависимости от того, как настроен php-fpm (слушает на порту или через сокетный файл) необходимо настроить nginx. В данном примере подразумевается, что php-fpm слушает на 9000 порту.

Открываем конфигурационный файл php-fpm:

Снимаем комментарий со следующей строки:

Проверяем настройку nginx, перезапускаем его и php-fpm:

systemctl restart nginx

systemctl restart php-fpm

Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:

Долгие запросы

С помощью длительных запросов к веб-серверу или СУБД можно сделать выводы о том, что является узким местом в работе сервиса.

MySQL / MariDB

Для начала, воспользуемся инструкцией, чтобы настроить ведение лога медленных запросов (для MySQL или MariaDB).

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

PHP-FPM

Открываем конфигурационный файл:

Редактируем следующие параметры:

request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/www-slow.log

* request_slowlog_timeout определяет время, в течение которого должен выполняться запрос, чтобы он считался медленным; slowlog — путь до лога, куда будет сохранена информация о медленных запросах.

systemctl restart php-fpm

Непрерывный просмотр лога можно запустить командой:

Источник

linux-notes.org

Проверка нагрузки на web-сервер с ab для Linux и Unix

Хочу рассказать в теме «Проверка нагрузки на web-сервер с ab для Linux и Unix» как можно протестировать нагрузку на сервер. Сделать можно это с утилитой Apache benchmark – это одна из самых простых утилит для тестирования нагрузки на сайты. Поставляется она вместе с веб сервером apache и не нуждается в настройке. Основной задачей apache benchmark (ab)– это показать каким количеством запросов можно «положить» веб-сервер и как быстро они выполняются.

Для того чтобы воспользоваться утилитой ab, нужно выполнить следующее:

Сейчас я поясню где и что, параметр «-с 10» – задает количество параллельных запросов, «-n 100» — это параметр который задает общее число запросов, а http://linux-notes.org/ – это мой сайт для тестирования.

Сайт для тестирования должен быть вводится в формате :
ab [options] [http[s]://]hostname[:port]/path

утилита ab с опиями

Все что выдаст можно увидеть у меня на рисунке ниже — это отчёт по нагрузке тестирующего сайта с помощью утилиты Apache benchmark:

Отчет о проведенной работе утилиты ab

Как видно с рисунка, я использую макбук и тестирую свой сайт. УБЕДИТЕЛЬНАЯ ПРОСЬБА, НЕ ТЕСТИРУЙТЕ ПОЖАЛУЙСТА ДАННЫЙ САЙТ и не выводите его из работы.

Сейчас поговорим о параметрах которые особо важны:

• Concurrency Level (количество одновременно-отправляемых запросов) — у меня их 10;
• Time taken for tests (тысяча запросов к серверу ) заняла 103 секунды (полное время на тестирование);
• Complete requests: успешно получены ответы (100) на всю тысячу запросов;
• Failed requests (не выполненные запросы) — у меня их 0;
• Write errors (ошибки записи) — у меня их 0;
• Total transferred (суммарный объем переданных данных) 8856700 байт;
• HTML transferred (из них «нужного» HTML) — 8800300 байт;
• Requests per second [#/sec] (mean)- это среднее количество запросов в секунду и заняло у меня 0.91 сек
• Time per request: 602.307 [ms] (mean) – втечении этого времени выполнились 10 параллельных запросов
• Time per request: 60.231 [ms] (mean, across all concurrent requests) – среднее время выполнения одного запроса
• Transfer rate: это скорость обмена данными с сервером и составила 79.2 кБ за секунду.
• Percentage of the requests served within a certain time (ms) – доля запросов на единицу времени. Тут видно, что 50% запросов выполнились менеее чем за пол секунды, а самый долгий запрос выполнялся 2 секунды(100% 2044 ms).

Изменяя параметры -n и -c можно отслеживать поведение сервера под нагрузкой.

Параметры ab

• -c — С данной опцией можно определить количество параллельных запросов.
• -n —С данной опцией можно определять количество отправляемых запросов на сайт.
• -t —С данной опцией можно задавать максимальное количество секунд.
• -C cookie-name=value —С данной опцией можно добавлять cookie в каждый запросу.
• -H — С данной опцией можно задававть заголовок для запроса.
• -T —С данной опцией можно задать Content-type.
• -p —С данной опцией можно задавать файл содержащий тело POST запроса.

Вот и все, моя статья «Проверка нагрузки на web-сервер с ab для Linux и Unix» подошла к завершению.

One thought on “ Проверка нагрузки на web-сервер с ab для Linux и Unix ”

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

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

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник

Локальный веб-сервер под Linux, с автоматическим поднятием хостов и переключением версий PHP

Скорее всего какие-то части этой статьи уже знакомы многим хаброжителям, но в связи с покупкой нового рабочего ноутбука я решил собрать все крупинки воедино и организовать удобное средство для разработки. Мне часто приходится работать со множеством маленьких проектов, с разными версиями PHP, часто переводить старые проекты на новые версии. В далёком прошлом, когда я был пользователем Windows то использовал OpenServer. Но с переходом на Linux мне нехватало той простоты создания хостов и переключений версий которые были в нём. Поэтому пришлось сделать еще более удобное решение на Linux =)

будет запущен тот же файл но уже с версией PHP 7.2.7

Другие версии доставляются аналогичным описанным ниже способом.

Для создания еще одного сайта просто создаем в /var/www/ папку имеющую окончание .loc, внутри которой должна быть папка public_html являющаяся корнем сайта

Вот собственно и все. Как без дополнительных мучений, перезапусков, и редактирований конфигов имеем автоматическую систему для работы с сайтами.

Всё это я проверну на LinuxMint19, он на базе Ubuntu18.04, так что с ним все будет аналогично.

Для начала поставим необходимые пакеты

Postfix ставим в качестве плюшки, как простое решение(в мастере установки, всё по умолчанию выбираем) для отправки почты с локальной машины.

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

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

Создадим папку в которой будем собирать исходники PHP для разных версий

Также нам понадобится папки для CGI скриптов

И runtime папка для этих же скриптов, с правами

И так как каталог у нас находится в оперативной памяти, добавим его создание при старте системы, для этого добавим в /etc/tmpfiles.d/fcgid.conf

У меня dnsmasq-base идет с коробки, если нет то его всегда можно доставить.

Добавим правило в его конфигурацию. Найти файл конфигурации dnsmasq.conf можно так

Либо если он как и у меня является частью NetworkManager то создать новый файл конфигурации в /etc/NetworkManager/dnsmasq.d/local.conf
Добавим в него строчку для перенаправление нашего локального домена на локальную машину.

Также нужно включить необходимые модули апача

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

1. Скачиваем исходники нужной версии и распаковываем их

2. Cобираем из исходников нужную версию PHP, и помещаем ее в /opt/php-5.6.36

3. Создаем CGI для обработки этой версии в /var/www/cgi-bin/php-5.6.36.fcgi

4. Делаем файл исполняемым

5. Добавляем экшен для обработки каждой версии в /etc/apache2/mods-available/fcgid.conf

6. Добавляем правило для обработки каждой версии в /etc/apache2/sites-available/000-default.conf

Ну вот и всё. Осталось только перезапустить apache и dnsmasq и пользоваться

Источник