Тюнинг nginx

Настройка NGINX

Продолжим тюнинг nginx, настроив несколько основных параметров, отвечающих за количество обрабатываемых соединений и сроки их поддержания.

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

а) во FreeBSD:

vi /usr/local/etc/nginx.conf

б) в Linux:

vi /etc/nginx/conf/nginx.conf

… или, если nginx ставился из пакетов:

vi /etc/nginx/nginx.conf

Пример настроенного nginx.conf:

worker_processes  auto;
worker_priority     -2;
…
events {
    worker_connections  2048;
    multi_accept on;
}
…
http {
    …
    keepalive_timeout          45;
    reset_timedout_connection  on;
    client_body_timeout        35;
    send_timeout               30;
    …
}

worker_processes, по умолчанию 1. Определяет количество рабочих процессов. Обычно, выставляют равному числу ядер, но в новых версиях его лучше устанавливать в auto.

worker_priority, по умолчанию 0. Задает приоритет рабочих процессов от -20 до 20 (отрицательное число означает более высокий приоритет). Ему стоит отдать чуть больший приоритет (-2). Это нужно для того, чтобы при сильной нагрузке на скриптовую часть сайта или DDoS атаке, nginx продолжал обрабатывать запросы и отдавать статику.

worker_connections, по умолчанию 512. Устанавливает максимальное количество соединений одного рабочего процесса, то есть nginx будет обрабатывать worker_processes * worker_connections, остальные запросы ставить в очередь. Следует выбирать значения от 1024 до 4096. В нашем примере — 2048.

multi_accept, по умолчанию off. Если включен, позволяет принимать максимально возможное количество соединений. Иначе, процесс nginx за один раз будет принимать только одно новое соединение.

keepalive_timeout, по умолчанию 75. Отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Для современных систем, стоит выставить от 30 до 50. В нашем случае 45.

reset_timedout_connection, по умолчанию off. Если клиент перестал читать страницу, Nginx будет сбрасывать соединение с ним.

client_body_timeout, по умолчанию 60. Будет ждать выставленное количество секунд тело запроса от клиента, после чего сбросит соединение. Значение по умолчанию слишком высокое и мы его снизили до 35.

send_timeout, по умолчанию 60. Если клиент прекратит чтение ответа, Nginx подождет выставленное количество секунд и сбросит соединение.

Как работает веб-сервер Apache?

Хоть Apache и называется веб-сервер, но в реальном положении вещей он является не сервером, а программой, которая запускается на сервере. Его задача установить соединение между сервером и браузером посетителей (Firefox, Google Chrome, Safari и др.) при доставке файлов туда и обратно между ними (клиент-серверная структура). Apache – это кроссплатформенное программное обеспечение, что значит оно хорошо работает как на Unix, так и на Windows серверах.

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

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

Знаете ли вы, что в Hostinger есть специальные предложения? Посетите нашу страницу купонов и сэкономьте до 75%! Не стоит забывать, что это предложение ограничено во времени!

Основы

Чтобы наш сервер мог распределять нагрузку, создадим группу веб-серверов, на которые будут переводиться запросы:

vi /etc/nginx/conf.d/upstreams.conf

* в данном примере мы создаем файл upstreams.conf, в котором можем хранить все наши апстримы. NGINX автоматически читает все конфигурационные файлы в каталоге conf.d.

Добавим:

upstream dmosk_backend {
    server 192.168.10.10;
    server 192.168.10.11;
    server 192.168.10.12;
}

* предполагается, что в нашей внутренней сети есть кластер из трех веб-серверов — 192.168.10.10, 192.168.10.11 и 192.168.10.12. Мы создали апстрим с названием dmosk_backend. Позже, мы настроим веб-сервер, чтобы он умел обращаться к данному бэкенду.

В настройках сайта (виртуального домена) нам необходимо теперь проксировать запросы на созданный upstream. Данная настройка будет такой:

server {
    …
    location / {
        proxy_pass http://dmosk_backend;
    }
    …
}

Проверяем корректность нашего конфигурационного файла:

nginx -t

Если ошибок нет, перезапускаем сервис:

systemctl restart nginx

Как в NGINX сделать редирект на мобильную версию сайта

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

### Устанавливаем переменную в 0. В неё пишем 1, если обнаружили мобильную версию браузера
set $mobile_rewrite 0;

if ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino") {
  set $mobile_rewrite 1;
}

if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez(0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-)|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10|n20|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-(|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)") {
  set $mobile_rewrite 1;
}
### Мобильный барузер обнаружен, редиректим на мобильный поддомен, в моём случае, m.example.com
if ($mobile_rewrite = 1) {
    rewrite ^ http://m.example.com/$request_uri redirect;
    break;
} 

Шаг 3 – Установка PHP и настройка Nginx для использования процессора PHP

Теперь у вас есть Nginx для обслуживания ваших страниц и MySQL для хранения и управления данными, однако у вас до сих пор не установлено ПО, которое может генерировать динамический контент. Для этого требуется установить PHP.

Поскольку Nginx не поддерживает нативную обработку PHP, как некоторые другие веб-серверы, вам потребуется установить , т.е. «менеджер процессов fastCGI». Мы укажем Nginx передавать запросы PHP в это программное обеспечение для обработки.

Примечание. В зависимости от поставщика облачных услуг вам может потребоваться установить хранилище Ubuntu , которое включает бесплатное программное обеспечение и программное обеспечение с открытым исходным кодом, поддерживаемое сообществом Ubuntu, прежде чем устанавливать пакет . Для этого можно ввести следующую команду:

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

Теперь у вас установлены все требуемые компоненты набора LEMP, однако вам нужно внести еще несколько изменений конфигурации, чтобы Nginx использовал процессор PHP для динамического контента.

Это изменение конфигурации выполняется уровне блока сервера (блоки сервера похожи на виртуальные хосты в Apache). Откройте новый файл конфигурации блока сервера в каталоге . В этом примере новый файл конфигурации блока сервера имеет имя , хотя вы можете использовать любое желаемое имя:

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

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

/etc/nginx/sites-available/example.com

Ниже описано действие этих директив и блоков расположения:

• — определяет, что будет прослушивать порт Nginx. В данном случае он будет прослушивать порт , используемый по умолчанию для протокола HTTP.
• — определяет корневой каталог документа, где хранятся файлы, обслуживаемые сайтом.
• — задает для Nginx приоритет обслуживания файлов с именем (при наличии) при запросе файла индекса.
• — определяет, какой серверный блок должен использоваться для заданного запроса вашего сервера. Эта директива должна указывать на доменное имя или публичный IP-адрес вашего сервера.
• — первый блок расположения включает директиву , которая проверяет наличие файлов, соответствующих запросу URI. Если Nginx не сможет найти соответствующий файл, будет возвращена ошибка 404.
• — этот блок расположения отвечает за фактическую обработку PHP посредством указания Nginx на файл конфигурации и файл file, который объявляет, какой сокет ассоциирован с .
• — последний блок расположения отвечает за файлы , которые Nginx не обрабатывает. При добавлении директивы из файлов в корневой каталог документа они не будут выводиться посетителям.

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

Затем уберите ссылку на файл конфигурации по умолчанию из каталога :

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

Протестируйте новый файл конфигурации на ошибки синтаксиса:

При появлении сообщений о каких-либо ошибках, вернитесь и повторно проверьте ваш файл, прежде чем продолжать.

Когда вы будете готовы, перезагрузите Nginx для внесения необходимых изменений:

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

Управление скоростью и безопасностью сервера и сайта

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

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

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

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

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

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

Кэширование сайта
Основная задача кэширования — ускорение работы программы, загрузки сайта и т.д. Время извлечения из кэша меньше, нежели получение информации из какого-то удаленного источника. Чем чище кэш браузера, тем легче работать с ресурсом. Для обеспечения высокой скорости загрузки страниц, закачки приложений и файлов, появления минимум ошибок “Time out” на странице, сбрасывайте время от времени кэш сайта. 

Уменьшите количества переадресаций
Перенаправление создает дополнительные HTTP-запросы, которые негативно влияют на производительность сайта. Чем больше редиректов задерживает страницу, тем больше это приводит к задержкам при перенаправлении и замедляет скорость загрузки веб-страницы. Проверьте, какие редиректы у вас настроены, и по возможности отключите неактуальные. Так сайт будет быстрее загружаться, что способствует увеличению количества посетителей, лучшей видимости для пользователей в поисковой выдаче и, как следствие, высокой доходности. 

Лучшие инструменты для проверки показателей сайта

Скорость загрузки страницы влияет на производительность практически во всех сферах — от пользовательского опыта до поисковой оптимизации. Большинство посетителей сайта будут ждать загрузки страницы от 2 до 4 секунд, прежде чем перейти к другому сайту в списке. И нельзя обойти стороной тот факт, что более быстрый сайт будет работать лучше. Но не всегда просто понять, с чего нужно начать. Я рекомендую вам периодически проводить мониторинг сайтов с помощью простых онлайн-инструментов, о которых я расскажу ниже. 

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

SupportPRO ScannerSupportPRO — это бесплатный инструмент для сканирования серверов и сайтов, который поможет выявить проблемы производительности и дыры в безопасности, связанные с веб-сервером. Пользователю достаточно указать свой домен, и сканер начнет анализировать весь сайт, предоставляя полный список обнаруженных на нем недостатков. Уникальные тесты, которые выполняет сканер SupportPRO, включают текущее состояние безопасности, производительности, подключения, сети или хранилища. Пользователи могут мгновенно протестировать производительность веб-серверов без ущерба для общей производительности сервера. На сайте разработчика есть круглосуточная поддержка, которая всегда готова помочь владельцам сайтов в исправлении ошибки, а также повысить общую производительность сайта.

Acunetix  Acunetix — это инструмент для обнаружения уязвимостей сайтов, в котором инженеры компании внедрили технологию сканирования на предмет безопасности веб-приложений. Она охватывает 360-градусный вид сайта. Этот сервис имеет множество уникальных функций: AcuSensor Technology, SQL-инъекция и межсайтовое скриптовое тестирование, тестирование безопасности приложений Ajax и Web 2.0, механизмы двухфакторной аутентификации и т.д.GTmetrix
Одним из лучших бесплатных инструментов для тестирования скорости сайта в 2019 году является GTmetrix. Этот инструмент невероятно простой в использовании. Вы просто вводите свой URL и нажимаете «Анализ». При бесплатной регистрации возможно проверить скорость загрузки сайта из семи различных локаций. Этот инструмент позволяет выбрать браузер Firefox или Chrome. GTmetrix имеет и другие уникальные функции: воспроизведение видео для выполнения анализа и выявления проблем при загрузке, возможность запуска Adblock Plus. Google PageSpeed InsightsPageSpeed Insights позволяет получить рекомендации по ускорению отображения страницы в браузере. Этот инструмент оценивает сайт по шкале от 1 до 100. Чем выше число, тем лучше оптимизирован ваш сайт. Значение от 85 и выше указывает на то, что ресурс работает хорошо. PageSpeed Insights анализирует содержимое вашей веб-страницы, после чего генерирует отчет с рекомендациями по улучшению скорости загрузки. Также PageSpeed предоставляет отчет о производительности как для десктопной, так и для мобильной версии сайта.

Оптимизация работы с файлами

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

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

позволит передавать заголовок ответа и начало файла в одном пакете.

по умолчанию выключена. Задает настройку для кэширования информации о файлах, с которыми работает nginx. По умолчанию выключено.

задает время, через которое веб-сервер будет проверять актуальность данных. По умолчанию 60 секунд.

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

Общая настройка NGINX

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

Модули, из которых состоит NGINX, можно настроить при помощи директив, которые, в свою очередь, подразделяются на простые и блочные. Блочная директива отличается от простой тем, что в ней содержатся дополнительные инструкции. Контекст – это блочная директива, внутри которой можно задавать другие директивы. Что касается блоков, то для настройки NGINX необходимо остановиться на следующих разновидностях: блок server отвечает за конфигурацию для виртуального сервера, в блоке http (в котором находится блок server) прописываются директивы HTTP-сервера, а блоки location определяют конфигурацию в зависимости от URI-запроса.

Теперь перейдем к самому процессу настройки NGINX.

Для начала необходимо настроить файл nginx.conf:

$ sudo nano /etc/nginx/nginx.conf

В этом файле Вы можете посмотреть все основные параметры. Рассмотрим, что обозначает каждая из директив:

• User – пользователь и группа, права которых будут использоваться для запуска рабочего процесса;
• worker_processes – число рабочих процессов (воркеров). Рекомендуется поставить значение “auto”, т.к. число будет равно числу процессорных ядер;
• error_log – конфигурирует запись в лог;
• pid — определяет, в каком файле будет храниться номер основного процесса;

блок events:

• worker_connections – определяет максимальное количество соединений, которые одновременно может открыть рабочий процесс;
• use — метод, который будет использоваться для обработки соединений;
• multi_accept — определяет, какое количество соединений будет принимать рабочий процесс за один раз (on – все новые соединения; off – только одно новое соединение);

блок http:

• include – включение файла или файлов, которые подходят под заданную маску;
• default_type — тип данных по умолчанию;
• server_tokens – позволяет включить (on) или отключить (off) вывод версии NGINX в заголовках ответа или ошибках;
• sendfile – позволяет включить (on) или отключить (off) метод отправки данных sendfile();
• sendfile_max_chunk — определяет объем данных, который может передаваться за один вызов sendfile. Если установить на ноль, то одно быстрое соединение может полностью захватить рабочий процесс;
• tcp_nopush – при включении позволяет передавать заголовок ответа и начало файла одним пакетом, а также передавать файл целым пакетом;
• reset_timedout_connection — позволяет включить (on) или отключить (off) сброс соединений по таймауту;
• client_header_timeout – определяет время, за которое клиент должен успеть передать полностью заголовок;
• client_body_timeout – определяет таймаут при чтении тела запроса клиента;
• send_timeout – задается время, по истечении которого соединение закрывается, если клиент ничего не принимает;
• client_header_buffer_size – определяет буфер для чтения заголовка запроса клиента (по умолчанию равняется 1K);
• client_body_buffer_size – определяет буфер для чтения тела запроса клиента;
• client_max_body_size – определяет максимально допустимый размер тела запроса клиента;
• access_log — позволяет включить (on) или отключить (off) лог доступа;
• include – подключение дополнительных конфигураций.

Кэширование Nginx и fastcgi

proxy_cache_path /home/vagrant/Code/ng-cache levels=1:2 keys_zone=ng_cache:10m max_size=10g inactive=60m;
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
fastcgi_cache_path /home/vagrant/Code/ngd-cache levels=1:2 keys_zone=ngd_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;

server {
    listen 80;
    listen 443 ssl http2;
    server_name nginx-performance.app;
    root "/home/vagrant/Code/project-nginx/public";

    index index.html index.htm index.php;

    charset utf-8;

    proxy_cache ng_cache;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/nginx-performance.app-error.log error;

    sendfile off;

    client_max_body_size 100m;

    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_intercept_errors off;
        fastcgi_buffer_size 16k;
        fastcgi_buffers 4 16k;
        fastcgi_connect_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;


      fastcgi_cache ngd_cache;
      fastcgi_cache_valid  60m;
    }

    location ~ /.ht {
        deny all;
    }

    ssl_certificate     /etc/nginx/ssl/nginx-performance.app.crt;
    ssl_certificate_key /etc/nginx/ssl/nginx-performance.app.key;
}

Мы открыли файл виртуального хоста Nginx и добавили приведенные выше настройки. Давайте поясним их.

proxy_cache_path /home/vagrant/Code/ng-cache levels=1:2 keys_zone=ng_cache:10m max_size=10g inactive=60m;

Как объяснялось в статье производительность Apache и Nginx: методы оптимизации, proxy_cache_path используется для кеширования статических ресурсов. Таких как изображения, таблицы стилей, файлы JavaScript. Сам путь должен существовать, поэтому необходимо создать эти директории.

levels означает глубину директорий внутри этого пути/папки.

Keys zone –  это имя. Каждый виртуальный хост должен использовать отдельное имя. max_size означает максимальный размер кэша, а inactive — что элементы времени будут храниться в кэше, даже если они не запрашиваются.

После этого времени простоя кэш для ресурса будет снова заполнен.

fastcgi_cache_purge

Это определяет запросы, которые смогут очистить кэш. Nginx (его модуль ngx_http_fastcgi_module) предоставляет полный комплект инструментов для кэширования. Пример использования указанной выше директивы:

fastcgi_cache_path /data/nginx/cache keys_zone=cache_zone:10m;
map $request_method $purge_method {
    PURGE   1;
    default 0;
}

server {
    ...
    location / {
        fastcgi_pass        backend;
        fastcgi_cache       cache_zone;
        fastcgi_cache_key   $uri;
        fastcgi_cache_purge $purge_method;
    }
}

В этом случае запрос PURGE REST сможет удалить данные из кэша.

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

add_header NGINX_FASTCGI_CACHE $upstream_cache_status;

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

Метод fastcgi_cache_methods полезен для кеширования конкретных методов запроса, таких как POST. GET и HEAD.

Активировав приведенную выше конфигурацию, как для статического, так и для динамического контента, мы запустили Locust. Мы подключили к системе 100 параллельных пользователей. Разница в результатах была поразительной. Того напряжения, в котором раньше находился сервер, уже не ощущалось.

Кэширование Nginx принесло несколько значительных улучшений.

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

Мы также протестировали одну страницу галереи, у которой есть дополнительный «багаж» похожих и новых галерей.

Отчет в файле HAR по этому тесту.

Основные ошибки nginx и их устранение

502 Bad Gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в прописаны правильные права

listen = /tmp/php5-fpm.sock 
listen.group = www-data
listen.owner = www-data

504 Gateway Time-out

Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:

server { 
... 
   send_timeout 800;
   proxy_send_timeout 800;
   proxy_connect_timeout 800;  
   proxy_read_timeout 800;  
... 
}

Тут мы выставили ожидание таймаута в 800 секунд.

Upstream timed out (110: Connection timed out) while reading response header from upstream

Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута

location ~ \.php$ { 
   include fastcgi_params;
   fastcgi_index index.php; 
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
   fastcgi_pass unix:/tmp/php5-fpm.sock;  
   fastcgi_read_timeout 800;
}

800 секунд на ожидание ответа от бекенда.

413 Request Entity Too Large

Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку

client_max_body_size 1m;

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

client_max_body_size 100m;

Также, можно отключить проверку размера тела ответа полностью значением ноль:

client_max_body_size 0;

304 Not Modified не устанавливается

Если возникает проблема с правильным отображением ответного заголовка сервера , то проблема, скорее всего, в пунктах:

• В секции конкретного сайта включен (). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
• установить в , то есть на уровне или конкретного прописать: