Производительность Apache против Nginx: методы оптимизации

 location ~ \.php$ { fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; } 

Поскольку FastCGI — это протокол, отличный от HTTP, первые две строки пересылают некоторые аргументы и заголовки в php-fpm, а третья строка указывает способ прокси нашего запроса — через сокет локальной сети.

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

Но если мы размещаем всю нашу установку в одной системе, мы должны использовать сокет Unix для подключения к процессу прослушивания php:

 fastcgi_pass unix:/var/run/php7.0-fpm.sock; 

Считается, что сокеты Unix имеют лучшую производительность, чем TCP , и эта настройка считается более безопасной. Вы можете найти более подробную информацию об этой установке в этой статье Rackspace .

Этот совет, касающийся сокетов Unix, также применим для Apache. Подробнее здесь .

gzip_static : общепринятое мнение о производительности веб-сервера заключается в сжатии наших статических ресурсов. Это часто означает, что мы попытаемся пойти на компромисс и попытаться сжать только те файлы, которые превышают некоторый порог, поскольку сжатие ресурсов на лету при каждом запросе может быть дорогостоящим. Nginx имеет директиву gzip_static которая позволяет нам обслуживать сжатые версии файлов — с расширением .gz — вместо обычных ресурсов:

 location /assets { gzip_static on; } 

Таким образом, Nginx будет пытаться обслуживать style.css.gz вместо style.css (в этом случае мы должны позаботиться о style.css ).

Таким образом, циклы ЦП не будут тратиться на сжатие «на лету» для каждого запроса.

Кеширование с помощью Nginx

Рассказ о Nginx не будет полным без упоминания о том, как кэшировать контент. Кэширование Nginx настолько эффективно, что многие системные администраторы не думают, что отдельные уровни для кэширования HTTP, такие как Varnish, имеют большой смысл. Возможно, это менее сложный, но простота является особенностью . Включить кеширование с помощью Nginx довольно просто.

 proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m; 

Это директива, которую мы помещаем в наш файл виртуального хоста, вне блока server . Аргумент proxy_cache_path может быть любым путем, в котором мы хотим сохранить наш кэш. levels определяют, сколько уровней каталогов Nginx должен хранить в кэшированном контенте. Из соображений производительности обычно приемлемы два уровня. Повторение через каталоги может быть дорогостоящим. Аргумент keys_zone — это имя зоны совместно используемой памяти, используемой для хранения ключей кэша, и 10m — это место для этих ключей в памяти (обычно достаточно 10MB; это не место для реального кэшированного содержимого). max_size является необязательным и устанавливает верхний предел для кэшируемого содержимого — здесь 10 ГБ. Если это не указано, оно займет все доступное пространство. inactive указывает, как долго контент может оставаться в кеше без запроса до его удаления Nginx.

Установив это, мы добавили бы следующую строку с именем нашей зоны памяти в server или в блок location :

 proxy_cache my_cache; 

Дополнительный уровень отказоустойчивости с Nginx может быть достигнут, сказав ему обслуживать элементы из кэша, когда он сталкивается с ошибкой сервера в источнике, или в вышестоящем сервере, или когда сервер не работает:

 proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; 

Более подробную информацию о директивах server или блока location для дальнейшей настройки кэширования Nginx можно найти здесь .

Директивы proxy_cache_* предназначены для статических ресурсов, но мы обычно хотим кэшировать динамический вывод наших веб-приложений — будь то CMS или что-то еще. В этом случае мы будем использовать директиву fastcgi_cache_* вместо proxy_cache_* :

  fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=my_cache:10m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; fastcgi_cache_use_stale error timeout invalid_header http_500; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; add_header NGINX_FASTCGI_CACHE $upstream_cache_status; 

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

Затем в нашем сервере или блоке местоположения мы можем установить некоторые исключения для кэширования — например, когда строка запроса присутствует в URL запроса:

 if ($query_string != "") { set $skip_cache 1; } 

Кроме того, в нашем блоке \.php внутри server , в случае PHP, мы добавили бы что-то вроде:

 location ~ \.php$ { try_files $uri =404; include fastcgi_params; fastcgi_read_timeout 360s; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php7.0-fpm.sock; fastcgi_index index.php; fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache; fastcgi_cache my_cache; fastcgi_cache_valid 60m; } 

Выше строки fastcgi_cache* и fastcgi_no_cache регулируют кэширование и исключения.
Подробные ссылки на все эти директивы можно найти на веб-сайте Nginx docs .

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

Вывод

Мы попытались представить некоторые методы, которые помогут нам улучшить производительность нашего веб-сервера, и теорию, лежащую в основе этих методов. Но эта тема никоим образом не исчерпана: мы до сих пор не рассмотрели настройки обратного прокси-сервера, состоящие из Apache и Nginx, или многосерверных установок. Достижение наилучших результатов на обоих этих серверах — это вопрос тестирования и анализа конкретных реальных случаев. Это своего рода бесконечная тема.