Настройка сервера

Краткий гайд про то, как можно настраивать nginx, php-fpm и mysql для оптимального потребления ресурсов сервера.

В прошлом году я рассказал про антипаттерн, который приводит к плохому быстродействию сайтов и является одной из самых частых проблем быстродействия проектов. Второй такой причиной является отсутствие настройки целиком или плохие настройки программного обеспечения. Многие программы по-умолчанию настроены так, чтобы работать на очень слабых по современным меркам серверах, и не могут использовать все доступные мощности. Если максимально использовать ядра процессора и свободную оперативную память, сервер может выдерживать очень серьёзные нагрузки. Этот пост о том, как можно настроить nginx, php-fpm и mysql-совместимую базу данных, чтобы выжать максимум из железа.

Настройка Nginx

Веб-сервер Nginx обладает огромным количеством настроек и с нуля во всех разобраться довольно сложно. Я советую вам взять за основу структуру конфига с уже заданными неплохими значениями от проекта H5BP.

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

Если вы хостите php сайты, то вам необходимо добавить примерно такой кусочек, который можно назвать php.conf:

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

Для современных CMS и фреймворков, которые используют паттерн FrontController, вам нужно направлять все запросы на файл index.php. Ниже вариант конфига для WordPress и пара вариантов для фреймворков:

Вот два сайта, которые служат хорошим источником информации про nginx:
http://nginx.org/en/docs/
https://www.nginx.com/resources/wiki/

Настройка PHP-FPM

Настройка php-fpm — самая простая вещь. Задача заключается в том, чтобы посчитать, какое максимальное количество процессов запустить на вашем сервере. Математика следующая:

pm.max_children = (Общее количество свободной RAM — Резерв для системы) / Размер памяти для одного процесса.

Важный нюанс! Под общим количеством свободной памяти имеется в виду не физическая память, а то, сколько осталось памяти после того, как вы вычли память для базы, redis, memcache и прочего. Учитывайте, что на эти системы может уйти гигабайты памяти в зависимости от настроек. Тут следует подумать, что важнее — больше память для хранения и быстрого извлечения данных или же большое количество php процессов наготове.

Узнать средний размер потребления памяти для php процесса можно так:

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

Чаще всего я встречал использование динамического процесс менеджера, как наиболее гибкий вариант. Ниже я привожу пример конфигурации для сервера с 16 ГБ памяти. С учетом базы данных и прочего софта, у нас остаётся 6 ГБ свободной памяти, а команда показала, что в среднем наш процесс потребляет 90 мегабайт.

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

Настройка MySql

Настройки mysql-совместимой базы содержатся в файле my.cnf. Ниже опции, которые имеет смысл отредактировать:

Как узнать, сколько наш диск может операций в секунду:

В таблице результатов нас интересует среднее между read iops и write iops, значение в конфигурации для базы не должно превышать цифры в результатах.

После любых изменений, следует промониторить потребление процессоров и память, быстродействие. Иногда, приходится корректировать цифры, потому что расчётные значения могут не соответствовать реальным цифрам. Также не забывайте, что проверять следует на реальной нагрузке, цифры при спящем трафике могут разительно отличаться от полноценной дневной нагрузки. Самый просто способ — команда top, более продвинутые и удобные способы мониторинга — сервисы вроде NewRelic или Nginx Amplify

Надеюсь, это информация поможет вам при настройке вашего сервера.

3 частые проблемы производительности веб-приложений, первая проблема

Описываю самый распространённый анти-паттерн, который может быть в вашем коде прямо сейчас.

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

Дорогие запросы к базе данных внутри цикла.

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

Во-первых, тут присутствует красный флаг, о которым я писал ранее (https://dmitriynyu.com/perfomance-testing/) — нет ограничения на количества шагов в цикле. Код написан так, что мы вынуждены надеется, что количество айдишников, которое вернёт getIdsOfItemsInCart() будет небольшим, но на самом деле, мы этого точно не знаем.

Во-вторых, этот паттерн очень ловко маскируется. У вас в коде он может существовать не в таком явном виде, как в примере выше, это может быть например прикрепление свойств товара в интернет магазине к номенклатурной позиции. Менеджер добавил о 100 свойств к каждой детской игрушке — цвет, вес, форма и т.д., и теперь при каждом простом запросе вроде:

самописная и не очень умная ОРМ в глубине модели Item совершает 100 отдельных запросов к этим свойствам (это реальный случай).

В-третьих, этот вредный паттерн очень легко недооценить и проигнорировать. Например, внутри метода Item::first() может происходит кеширование. Полагаясь на это, вы подвергаете себя риску низкого быстродействия в случае, когда вдруг кэшу не хватит памяти и он решит почистить эти записи. Вполне реальна ситуация, когда в начале метод в цикле просто возвращал захардкоденные значения, а потом этот метод порефакторили, и он стал обращаться к базе. А про то, что метод вызывается до 100 раз в цикле, все забыли или не проверили.

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