Чеклист по оптимизации VPS на PHP/Mysql/Nginx

[@Aquahawk]

А вообще начать стоит с этого habrahabr.ru/post/53236/

[@UncleAndy]

worker_processes 1;

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

[@aivus]

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

[@golotyuk]

Посмотрел официальную документацию, на самом деле даже так:
The optimal value depends on many factors including (but not limited to) the number of CPU cores, the number of hard disk drives that store data, and load pattern. When one is in doubt, setting it to the number of available CPU cores would be a good start (the value “auto” will try to autodetect it).

Спасибо за замечание.

[@BulatZiganshin]

а в nginx используются блокирующие обращения к OS?

[@VBart]

Конечно, если других нет.

[@coh]

innodb_flush_log_at_trx_commit =0

Плохой совет.

habrahabr.ru/post/66684/
innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.

[@UncleAndy]

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

[@FrimInc]

В этом месяце еще не было.

[@bestxp]

На своем опыте получилось так что от unix-socket пришлось отказаться в пользу tcp, только тогда ушла ошибка ( connection refused by peer), и мало того стал быстрее работать, так что спорный вопрос какой то

[@Morfi]

Возможно стоило просто увеличить /proc/sys/net/core/somaxconn

[@lesovsky]

Тоже имхо неплохой чеклист

[@E_STRICT]

access_log off;

Насколько это важно для увеличения производительности?

[@lesovsky]

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

Для случаев когда логирование таки нужно оставить используют разные фокусы, типа buffer= для nginx, «отключение» fsync для rsyslog и т.п.

[@golotyuk]

Важность растет с ростом количества запросов, но существенно отражаться начнет с сотен запросов в секунду.

[@mayorovp]

expires max;

Мина замедленного действия. Сработает, когда надо будет обновить сайт. Применять можно только совместно с методикой включения версии файла в uri.

[@golotyuk]

Да, обычно делают что-то типа:
/filename-version.css
либо
/filename.css?version

Вроде второй случай не очень хорошо в некоторых браузерах работает.

[@mayorovp]

Вряд ли. Второй случай — это настолько древний трюк, что он даже «тайно» вошел в jquery (кто сходу может вспомнить, что делает именованный параметр cache в функции ajax)? Первый же вариант мне не нравится, поскольку дефис часто используется и в исходных названиях файлов.

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

[@kost]

/filename.css?version не будет кэшироваться.

[@mayorovp]

Даже при явном указании возможности кэширования в заголовках?

[@golotyuk]

Ходят слухи, что Chrome иногда игнорирует то, что находится после знака вопроса при установленом Cache-Control. Проверю.