Самый быстрый метод для оценки производительности любого сервера веб-приложений PHP с использованием MySQL или PostgreSQL онлайн урок.


Содержание

Введение

Типичные ситуации

Требования к проведению измерений

Цель измерения

Измерения инструментов

Как измерить производительность сервера PostgreSQL?

Что такое производительность PHP?

Заключение


Введение

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

Основная задача оценки производительности сервера заключается в том, что ее необходимо выполнить быстро, без использования специальных (прочитанных сложных) инструментов и, конечно же, до объявления о запуске приложения.

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

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

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

Типичные ситуации

1. Выбор хостинга и сервера

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

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

На общем собрании проекта ответственный руководитель проекта задает этот «простой» вопрос: «Итак, кто выберет хостинг и сервер? Я поставлю необходимую сумму бюджета проекта на следующем этапе». Обычно, желая этого, это не большая проблема.

Кроме того, пытаясь делегировать, «Боб, вы можете выполнить эту задачу?» не работает. Боб мгновенно находит и перечисляет по крайней мере дюжину неотложных и важных задач, которые прямо сейчас он на нем, и доставка нужна на вчера.

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

2. Является ли сервер достаточно мощным

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

Клиент спрашивает: «Является ли сервер мощным?» Ожидаемый ответ должен быть: «Да!». После развертывания руководитель проекта становится грустным, когда смотрит на время ответа веб-приложения. Возникает неприятная мысль: «Кто виноват?» а что мне делать?".

Он понимает, что конфигурация сервера должна быть выбрана сама по себе, но, с другой стороны, специалист не найден в регионе. На самом деле получается, что этот мощный сервер, дешевый VPS, параметры которого выглядят хорошо, разделяет ресурсы хоста с армией хостинг-клиентов. Клиент заплатил сервер в течение пяти лет и ничего не изменит.

3. & nbsp; Расширенный уровень: у Клиента есть Сервер и есть Администратор

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

Ни одно из наших предложений по замене или покупке нового сервера не принимается, поскольку, по мнению администратора, оно будет тормозить «ваше» приложение.

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

Менеджер проекта требует, чтобы команда давала четкое объяснение «почему приложение замедляется» и номера доказательств, показывающие «вину» сервера. Команда, как всегда, полна свободного времени, поэтому все рады принять решение проблемы и дать пиво специалисту из другого отдела для подсказки о том, «где копать».

  • Выбор серверного приложения и нагрузки

  • Оценка существующей емкости сервера

  • Уметь ответить на вопрос «Почему это так медленно?»

Подводя итог, нам нужно столкнуться с некоторыми ситуациями и определить, какие задачи нам нужно решить

Требования к проведению измерений

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

  • Мы хотим знать возможности сервера перед запуском в производство
  • Метод измерения должен быть быстрым и дешевым
  • Измерительный инструмент должен быть прост в использовании и установке на сервере
  • Результат измерения должен быть легко интерпретирован и сопоставлен

Цель измерения

Сервер приобретен, операционная система установлен, и демон sshd запущен. Откройте консоль и войдите в сервер. Черная консоль, зеленые буквы и мигающий немой курсор спрашивают вас: «Что дальше?» Пришло время подумать о том, что будет измерено, и о том, что представляет собой производительность.

До этого момента вопрос казался простым: «Чтобы начать любой бенчмарк, и все будет ясно». Теперь, когда мигающая консоль курсора, мысль зашла в тупик, и вы не можете ввести необходимые команды.

Какова производительность Web-приложения в значительной степени:

  • Скорость доступа к ЦП + ОЗУ
  • Скорость дисковой подсистемы
  • Производительность языка среды выполнения приложения (в этом case, PHP)
  • Конфигурирование базы данных (у нас есть MySQL или PostgreSQL)
  • И, конечно же, в приложении (по каким ресурсам он используется)

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

  • Для серверных компонентов: ЦП + ОЗУ и дисковая подсистема
  • Для программных компонентов: MySQL и PHP

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

Измерительные инструменты

Что такое & nbsp; sysbench ?

Я не могу лучше описать этот инструмент, чем его автор, поэтому я цитирую его описание:

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

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

Установить sysbench

Это просто:
apt-get install sysbench

Вы можете скомпилировать:

$. autogen.sh $. configure $ make

Проверить производительность ЦП

Для этого нам нужно выполнить расчет двадцать тысяч простых чисел.

$ sysbench --test = cpu --cpu-max-prime = 20000 run

По умолчанию расчет будет выполняться в одном ядре. Мы используем ключ -num-threads = N, если хотим воспользоваться преимуществами параллельных вычислений.

Результат теста:

Сводка выполнения теста: общее время: 17.3915s Общее количество событий: 10000 общее время, затрачиваемое на выполнение события: 17.3875 Статистика за запрос: мин: 1,66 мс: 1,74 мс максимум: 4,00 мс ок. 95 percentile: 2.03ms

Интересная вещь в этом тесте - это значение общего времени. Запуск теста на нескольких серверах, мы можем сравнить меры.

Вот пример этого тестового прогона на серверах, которые были под моей рукой на момент подготовки этой статьи.

perfomance_diagram_1

Примечания:

  • G2 примерно в три раза быстрее, чем A3
  • Простая версия VPS'ka на Reg.Ru за сопоставимый G2 за 4 месяца:)
  • Dev основанный на Xeon X3440, а также NUC i5
  • Удивительно, что те же результаты на четырех серверах
  • Возможно, это простое вычисление выполняется на тех же блоках ЦП, которые не отражают общую производительность процессора

Тестирование производительности диска

Проверка дисковой подсистемы выполняется в три этапа:

  • Подготовка (генерация) набора текстовых файлов
  • Выполнение тестирования, удаление индикаторов
  • Очистка корзины

Подготовка текстовых файлов:

$ sysbench --test = fileio --file-total-size = 70G prepare

Команда создаст набор файлов общим размером 70 гигабайт. Размер должен значительно превышать объем оперативной памяти для результата теста, не влияет на кеш операционной системы.

Выполнение теста:

$ sysbench --test = fileio --file-total-size = 70G --file-test-mode = rndrw --init-rng = on --max-time = 300 --max- request = 0 run

Тест будет выполнен в режиме произвольного чтения (rndw) в течение 300 секунд, после чего будут показаны результаты. Опять же, тест по умолчанию будет выполнен в одном потоке (число потоков: 1).

Очистить временные файлы:

$ sysbench --test = очистка файла

Пример результата теста:

Выполненные операции: 249517 Чтение, 166344 Запись, 532224 Другое = 948085 Чтение 3.8073Gb Написано 2.5382Gb Всего передано 6.3455Gb (21.659Mb сек) 1386.18 Запрошено в секундах Срочное выполнение теста: общее время: 300.0045s Общее количество событий: 415861 общее время, затраченное на выполнение события: 178.9646 Статистика за запрос: мин.: 0.00мс avg: 0.43ms max: 205.67 мс прибл. 95 процентиль: 0.16 мс Бессознательность потоков: события (avg stddev): 415861.0000 0.00 время выполнения (avg stddev): 178.9646 0.00

В качестве показателя производительности дисковой подсистемы вы можете использовать значение средней скорости передачи данных (в этом примере 21,659 Мб сек).

Посмотрим, что этот тест показан на моих серверах:

perfomance_diagram_2

Примечания:

  • Заметные подозрительно низкие значения скорости на всех проверенных серверах
  • На установленном SSD-накопителе NUC i5, независимо от того, сколько раз я запускал тест, значение скорости передачи данных всегда находилось в диапазоне от 1,5 до 2 Мб с

MySQL OLTP Performance Test

Тест проверяет скорость транзакций сервера MySQL, каждая транзакция состоит из запросов на чтение и запись.

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

Подготовка к тесту:

$ sysbench --test = oltp --oltp-table-size = 1000000 --mysql-db = test --mysql-user = root --mysql-password = pass prepare

Test run:

$ sysbench --test = oltp --oltp-table-size = 1000000 --mysql-db = test --mysql-user = root --mysql-password = pass --max-time = 60 - oltp-read-only = off -max-requests = 0 --num-threads = 8 run

Параметр --oltp-read-only может быть установлен в on. Затем будут выполняться только запросы на чтение, позволяющие базе данных оценивать режим скорости, например, подчиненную базу.

Результат теста:

Статистика тестирования OLTP: выполненные запросы: read: 564158 написать: 0 другое: 80594 всего: 644752 транзакций: 40297 (671,57 в секунду) deadlocks: 0 (0,00 в секунду) читать запросы на запись: 564158 (9402.01 per sec.) Другие операции: 80594 (1343.14 в секунду). Сводка выполнения теста: общее время: 60.0040s Общее количество событий: 40297 Общее время, затраченное на выполнение события: 479.8413 Статистика за запрос: мин: 1.14ms Среднее: 11,91 мкс макс: 70,93 мс прибл. 95 процентилей: 15,54 мс

Самое интересное в отчете указывается количество транзакций в секунду (транзакции в секунду).

Поскольку этот тест показал себя на серверах:

Примечания:

  • Конфигурация MySQL была одинаковой на всех серверах & nbsp;
  • Отсутствие существенных различий между серверами A3 и G2 удивительно
  • NUC i5 по сравнению с G2

Как измерить производительность PostgreSQL?

К сожалению, инструмент sysbench имеет встроенные инструменты для тестирования PostgreSQL. Но это не останавливает нас полностью, потому что вы можете использовать утилиту pgbench .

Стандартные сценарии по умолчанию для повторного запуска выполняют следующую транзакцию:

BEGIN; UPDATE pgbench_accounts SET abalance = abalance +: delta WHERE help =: помощь; SELECT abalance FROM pgbench_accounts WHERE help =: help; UPDATE pgbench_tellers SET tbalance = tbalance +: delta WHERE tid =: tid; UPDATE pgbench_branches SET bbalance = bbalance +: delta WHERE bid =: bid; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (: tid,: bid,: aid,: delta, CURRENT_TIMESTAMP); КОНЕЦ;

Чтобы создать прогон тестового примера:

$ pgbench -h localhost -U test_user -i -s 100 test

Мы проводим тесты:

$ pgbench -h localhost -U test_user -t 5000 -c 4 -j 4 test

Команда Keys означает, что клиент выполнит 4 5000 4 транзакций на поток. В результате будет выполнено 20 000 транзакций.

Результат:

начальный вакуум... конец. тип транзакции: TPC-B (вид) коэффициент масштабирования: 10 режим запроса: простое количество клиентов: 4 количество потоков: 4 количество транзакций на клиента: 5000 количество фактически обработанных транзакций: 20000 20000 среднее время ожидания: 0,000 мс tps = 3350.950958 (включая установление соединений) tps = 3357.677756 (исключая установление соединений)

Самое главное здесь: это tps.

Сравнительные тесты на разных серверах, к сожалению, нет.

Что такое производительность PHP?

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

Однако есть ситуации, когда sysbench показал хороший результат, а приложение PHP на сервере демонстрирует довольно посредственные показатели производительности.

Конечно, на результат влияют такие параметры, как:

  • PHP-версия
  • Наличие ускорителя
  • Как и что он скомпилирован PHP
  • Какие расширения включены

Я хотел бы иметь инструмент, который будет легко установить, и после того, как вы начнете давать четкие показатели производительности текущего PHP на сервере.

И, как этот инструмент не влияет на производительность дисковой подсистемы (или сети), измеряет только работу интерпретатора PHP на связке процессора и памяти.

Простое отражение привело к выводу, что:

  • Существующие инструменты все еще существуют
  • Можно выбрать подходящий алгоритм
  • Пока существует непреложность в алгоритме, мы можем сравнить полученные & nbsp; результаты

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

Для запуска:

$ wget github.com florinsky af-php-bench raw master build phpbm.phar $ php phpbm.phar

Сценарий выполняет десять тестов, разделенных на три группы:

  • Первая группа имеет общие операции (циклы, rand, создание удаления объектов)
  • Вторая группа тестов: проверяет строковые функции, взрывает взрыв, вычисляет хэши
  • Третья задача заключается в работе с массивами
  • Все измерения производятся в секундах

О выполнении отчета об испытаниях:

[ОБЩИЕ ПО] 1 10 Циклы (если, в то время как, делать)...................... 6.72s 2 10 Генерация случайных чисел................................ 3.21s 3 10 Объекты..................................... 4.82s Время:.. 14.76 [STRINGS] 4 10 Простые функции струн................... 13.09s 5 10 Explode Implode........................ 15.90s 6 10 Длинные Строки............................... 30,37s 7 10 String Hash.................................... 23.57s Время:.. 82.93 [ARRAYS] 8 10 Заполните массивы................................ 22.32s 9 10 Сортировка массива (целые ключи и значения)....... 17.17s 10 10 Сортировка массива (строковые ключи и значения)........ 14.29s Время:.. 53.79 ИТОГО ВРЕМЯ:. 151.47

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

Заключение

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

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

Для анализа поведения сервера atop и iostat может помочь. Если мы обработаем статистику на несколько дней (или дольше), и вы сможете просматривать почти все происходящее.

atop

Запись данных в файл:

$ atop -w tmp atop.raw 1 60

Чтение записи:

$ atop -r tmp atop.raw

iostat

Измерение использования ЦП:

$ iostat -c 1

Вывод:

% пользователь% nice% system% iowait% steal% idle 82,21 0,00 17,79 0,00 0,00 0,00 79,05 0,00 20,70 0,00 0,00 0,25 80,95 0,00 19,05 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,25 0,00 0,00...

Измерение подсистемы загрузочного диска:

$ iostat -xd dev sda 1

Вывод:

rkB s wkB s ждут r_await w_await svctm% util 0,00 2060,00 4,05 0,00 4,05 3,98 95,60 0,00 2000,00 3,97 0,00 3,97 3,95 96,40 0,00 1976,00 3,92 0,00 3,92 3,92 95,60 0,00 2008,00 3,95 0,00 3,95 3,93 96,00 0,00 2008,00 3,92 0,00 3,92 3,92 96,80 0,00 2020,00 4,03 0,00 4,03 4,00 97,60 0,00 2016,00 3,97 0,00 3,97 3,97 97,20...

И, конечно, вы можете используйте Munin & nbsp; или подобные программы & nbsp; для сбора статистики с сервера в течение длительного времени.

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