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

Nginx без downtime на продакшн системе / Nginx hot reload

5437

299

00:02:45

04.03.2019

Запущен первый курс мощной образовательной программы от Диджитализируй: «Основы компьютерных и веб-технологий с Python»
Вся информация и запись на курс здесь: 🤍l/course01

Сказать спасибо за это видео можно здесь — 🤍

В этом коротком видео рассказываем о том, как мы используем веб сервер Nginx без downtime на production системе в Salesbeat (🤍) и других проектах — про горячую перезагрузку, изменение конфигурации на боевом сервере и тд. Nginx рулит!

Downtime — период времени, в течение которого система недоступна, в том числе из-за web server узла.
Hot reload — перезагрузка программного узла без downtime.

В примерах используется Linux (Debian).

Настраиваем LetsEncrypt SSL сертификат для сайта
— 🤍

SSH авторизация по ключам — 🤍

Копирование больших многогигабайтных файлов по сети в Linux / Unix / Mac OS — 🤍

/ about /

Меня зовут Алексей Голобурдин, я программирую с 2004 года и на этом канале делюсь своим опытом. Я основатель и руководитель компаний:

— Диджитализируй 🤍, разрабатываем сложные IT системы для бизнеса;
— Salesbeat 🤍, комплексный модуль доставки для интернет магазинов.

Если у вас есть проект на разработку, пишите нам на hi🤍digitalize.team.

С другими предложениями, а также если вам нужна одна или несколько индивидуальных консультаций/уроков по разработке (3000 руб/час), пишите мне на alexey🤍salesbeat.pro.

Мои соц сети:
🤍
🤍
🤍

—

Диджитализируй!

Шаг 4 — Проверка функционала PHP

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

Создайте файл , содержащий вызов функции :

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

Убедитесь, что в Server API вверху страницы указано значение FPM/FastCGI. Раздел «Переменные PHP» в нижней трети страницы покажет, что параметр SERVER_SOFTWARE имеет значение Apache на Ubuntu. Это подтверждает, что модуль активен, и что Apache использует PHP-FPM для обработки файлов PHP.

Разница между Apache и Nginx

Хотя Apache и Nginx являются двумя основными игроками в бизнесе веб-сервера, охватывающим 50 процентов веб-трафика через Интернет, они отличаются друг от друга. Apache — это HTTP-сервер с открытым исходным кодом, тогда как Nginx — высокопроизводительный асинхронный веб-сервер и обратный прокси-сервер.
Поддержка, исправления ошибок и разработка приложений на HTTP-сервере Apache управляются и поддерживаются сообществом пользователей со всего мира и координируются Apache Software Foundation. Поддержка и обслуживание Nginx осуществляется компанией с таким же названием, которая была основана в 2011 году.
Основное различие между ними заключается в том, как обрабатываются запросы клиентов. Хотя Apache предоставляет множество модулей многопроцессорной обработки для обработки запросов клиентов и веб-трафика, Nginx сконструирован таким образом, чтобы одновременно обрабатывать несколько клиентских запросов с минимальными аппаратными ресурсами.
В HTTP-сервере Apache один поток связан только с одним соединением, тогда как один поток в Nginx может обрабатывать несколько соединений. Все процессы помещаются в цикл событий вместе с другими соединениями и управляются асинхронно. Этот процесс потребляет меньше памяти, что повышает производительность.
Apache имеет многопоточную архитектуру, которая не обладает масштабируемостью. С другой стороны, Nginx следует асинхронному методу, основанному на событиях, для обработки нескольких клиентских запросов. Его управляемая событиями архитектура разработана таким образом, чтобы обеспечить лучшую производительность даже при интенсивном движении.
Apache обслуживает статический контент с использованием обычных методов и обрабатывает динамический контент изначально внутри самого веб-сервера.С другой стороны, Nginx не имеет возможности обрабатывать динамический контент внутри компании. Фактически, он полагается на внешние процессы для исполнения.

Webserver benchmark: сравнение Nginx Unit, PHP-FPM и Apache — Часть 2 (дополненная)

1481

00:09:55

23.01.2019

В этом видео мы продолжаем изучать производительность популярных серверов с PHP: Nginx Unit, PHP-FPM и Apache (mod_php).
В первой части (🤍 мы получили интересные результаты, а также активный отклик о сообщества и разработчиков.
Во второй части мы поменяли инструмент тестирования (wrk вместо ab) и ввели дополнительные режимы тестирования для выявления лидера в разных режимах.
Результаты изменились значительно, мы узнали много нового.
Версии софта остались прежние: Ubuntu 18.04, PHP 7.2, Unit 1.7, Apache 2.4. В качестве нагрузки использовался wrk 4.1.0 с параметрами -t8 -c128 -d10 latency.

Профессиональное ускорение сайтов: 🤍
Тестирование скорости сайтов: 🤍p1ai/
Сервис оптимизации картинок: 🤍
Группа «Ускорение сайтов» в VK: 🤍
Метод Лаб в VK: 🤍
Метод Лаб в Facebook: 🤍
Метод Лаб в Twitter: 🤍

Общая информация

Прежде чем мы перейдем к более детальному сравнению Apache vs Nginx давайте рассмотрим общие характеристики этих веб-серверов.

Apache

Веб-сервер Apache был разработан Робертом МакКулом в 1995 году под руководством Apache Software Foundation. С 1999 и по сей день Apache — это проект Apache Software, и сейчас это одна из самых популярных их программ.

Начиная с 1996 года Apache был самым популярным веб-сервером на просторах интернета. Из-за такой популярности веб-сервер имеет много документации и комплексную поддержку со стороны других компаний.

Администраторы часто выбирают Apache из-за его гибкости, мощности и поддержки интеграции со многими продуктами. Его можно расширять через динамически загружаемые модули, также это позволяет поддерживать большое количество интерпретируемых языков программирования без подключения специального ПО.

Nginx

В 2002 году Игорь Сусоев начал работу над веб-сервером Nginx, он поставил перед собой цель решить проблему десяти тысяч подключений, которой были подвержены все известные на то время веб-серверы. Дело в том, что ни один из существующих веб-серверов, не позволял обрабатывать 10 тысяч запросов одновременно. Первый публичный релиз состоялся в 2004 году и цель была достигнута, благодаря реализации архитектуры, основанной на асинхронных событиях.

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

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

Apache vs Nginx, Who is the winner?

258

00:03:33

17.12.2020

#Apache #Nginx #Winner

Welcome to Kimavi Super Simple Educational Videos.

#Apache #Nginx #Winner

Apache vs Nginx, Who is the winner?

Apache and Nginx are the two most common Linux open source web servers in the world

Together, they are responsible for serving over 50% of traffic on the internet

What is Apache?

Apache is an open-source and free web server software that powers around 40% of websites around the world

The Apache HTTP Server, colloquially called Apache, is a free and open-source cross-platform web server software, released under the terms of Apache License 2.0. Apache is developed and maintained by an open community of developers under the auspices of the Apache Software Foundation

Apache was designed from the ground up as a web server, the default is usually to interpret requests as filesystem resources

It begins by taking the document root and appending the portion of the request following the host and port number to try to find an actual file

Basically, the filesystem hierarchy is represented on the web as the available document

What is Nginx?

NGINX is a well known open source project originally written by Igor Sysoev, a Russian engineer

Igor started the project in 2002 and made it public in 2004. Since that time NGINX has become a de‑facto standard for high‑performance, scalable websites

Tens of millions of active websites use NGINX, including 1 million busiest websites in the world

Companies like Airbnb, Box, Dropbox, Netflix, Tumblr, WordPress.com, and many others deploy NGINX for scalability and performance reasons

….

Thank you from Kimavi, Please visit us at Kimavi.Com for more Super Simple Educational videos

PageSpeed для Apache

Модуль для apache называется mod_pagespeed и может распространяться как пакет.

Установка модуля немного различается для различных систем. Рассмотрим 2 варианта.

CentOS

Устанавливаем пакеты at и wget:

Затем необходимо скачать установочный пакет:

* в данном примере мы загрузим пакет для 64-битной системы. Для 32-х нужно использовать ссылку https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_i386.rpm.

После можно ставить сам модуль:

Перезапускаем Apache:

Ubuntu

Загружаем установочный пакет:

Устанавливаем скачанный пакет командой:

После установки модуля, необходимо перезагрузить apache:

Настройка

а) если используем CentOS:

б) если используем Ubuntu:

Данный файл хорошо документирован комментариями. Приведем некоторые примеры для настроек.

1. Для отключения модуля находим:

и меняем на:

2. Для указания конкретного каталога хранения кэша меняем опцию для:

3. Путь хранения логов:

Для применения настроек не забываем перезапустить apache:

* данная команда отработает как на CentOS, так и Ubuntu.

Доступ к веб-интерфесу

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

Находим настройку:

И добавляем в нее доступ (Allow from …) — в итоге мы получим, примерно, следующее:

* в данном примере мы добавили разрешение использовать веб-интерфейс для узла 192.168.1.5 и всей подсети 192.168.0.0/24.

Перезапускаем сервис:

Открываем веб-интерфейс по адресу  — мы должны увидеть страницу Pagespeed Admin.

Конфигурирование web-сервера (apache, nginx, балансировка nginx) // Бесплатный урок OTUS

6376

224

01:31:13

24.10.2020

В рамках вебинара вы узнаете:
— как проводить установку apache и nginx;
— как настраивать apache на работу в качестве backend;
— как настраивать порты, проверять работоспособность (curl);
— как проводить настройку балансировки нагрузки на nginx:
— что такое балансировка и некоторые из её алгоритмов;
— какие возможности открывает nginx для балансировки;
— и как настроить upstream на бэкэнд apache.

Запишитесь, чтобы не пропустить!

«Administrator Linux.Basic» — 🤍

Преподаватель: Андрей Буранов — специалист по UNIX-системам

Подключайтесь к обсуждению в чате — 🤍
Пройдите опрос по итогам мероприятия — 🤍
Следите за новостями проекта:

— Facebook: 🤍
— Telegram: 🤍
— ВКонтакте: 🤍
— LinkedIn: 🤍
— Хабр: 🤍

Настройка 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 подождет выставленное количество секунд и сбросит соединение.

Минимизация CSS и Javascript

Минимизация данных файлов означает удаление ненужных символов из HTML, JavaScript и CSS , которые не требуются для отображения страницы, такие как: Пробелы Комментарии Разделители блоковЭто ускоряет время загрузки, посредством уменьшения объема кода, который должен быть запрошен с сервера.Существуют плагины, позволяющие минимизировать данную задачу:JavaScript Grunt: grunt-contrib-uglify Gulp: gulp-uglifyCSS Grunt: grunt-contrib-cssmin Gulp: gulp-minify-cssЕсли используется WordPress, то можно также минимизировать CSS и Javascript с помощью WordPress Cache Enabler.Ресурсы, блокирующие рендерингКогда дело доходит до анализа скорости веб — страниц, всегда надо принимать во внимание то, что может быть блокирован DOM , вызывающий временами задержки загрузки страницы. Распространён термин «ресурсы, блокирующие рендеринг» (render blocking resources)

Как правило речь идёт о HTML, CSS, JavaScript и шрифтах. Вот несколько рекомендаций, как предотвратить блокировку рендеринга.CSS1. Правильно вызывать CSS-файлы2. Когда браузер находит в документе ссылку на CSS-файл, он приостанавливает процесс визуализации и начинает формировать модель CSSOM. Чтобы ускорить процесс, упрощайте CSS и используйте медиазапросы. Также убедитесь, что браузер может быстро скачать CSS-файлы.3. Уменьшить количество CSS-файлов (объединить CSS файлы в один файл)4. Минимизировать сам файл CSS (удалить лишние пробелы, символы, комментарии и т.д.)5. Использовать меньше CSS в целомJavascriptВ этом случае есть несколько хороших способов, которые надо всегда иметь в виду:1. Переместить скрипт к нижней части страницы, прямо перед тегом

На карте хорошо видно, что задержка возрастает по мере удаления геолокации от местоположения сервера, на котором размещён сайт.

Location	Requests	Min	Max	Avg	Std Dev	Loss
New York	4	130.034 ms	130.296 ms	130.113 ms	0.376 ms	0%
Miami	4	203.037 ms	214.867 ms	209.197 ms	4.598 ms	0%
Dallas	4	176.115 ms	176.211 ms	176.159 ms	0.422 ms	0%
San Francisco	4	192.953 ms	193.290 ms	193.105 ms	0.122 ms	0%
Seattle	4	197.142 ms	197.337 ms	197.257 ms	0.550 ms	0%
Toronto	4	154.615 ms	155.273 ms	154.790 ms	0.556 ms	0%
Frankfurt	4	47.339 ms	47.393 ms	47.368 ms	0.155 ms	0%
London	4	61.938 ms	62.470 ms	62.198 ms	0.362 ms	0%
Paris	4	59.335 ms	59.441 ms	59.387 ms	0.301 ms	0%
Amsterdam	4	45.190 ms	46.016 ms	45.447 ms	0.363 ms	0%
Sao Paulo	4	274.173 ms	274.840 ms	274.479 ms	0.252 ms	0%
Singapore	4	199.613 ms	200.768 ms	200.227 ms	0.428 ms	0%
Sydney	4	347.082 ms	347.135 ms	347.109 ms	0.721 ms	0%
Tokyo	4	141.181 ms	148.344 ms	144.084 ms	2.909 ms	0%

Задержки при обращении к серверу bmstu-kaluga.ru через CDN

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

Location	Requests	Min	Max	Avg	Std Dev	Loss
New York	4	0.844 ms	1.028 ms	0.918 ms	0.070 ms	0%
Miami	4	0.379 ms	0.430 ms	0.400 ms	0.027 ms	0%
Dallas	4	0.293 ms	0.325 ms	0.308 ms	0.016 ms	0%
San Francisco	4	1.875 ms	2.165 ms	2.004 ms	0.119 ms	0%
Seattle	4	0.261 ms	0.477 ms	0.375 ms	0.080 ms	0%
Toronto	4	0.435 ms	0.722 ms	0.520 ms	0.121 ms	0%
Frankfurt	4	0.614 ms	0.686 ms	0.656 ms	0.036 ms	0%
London	4	1.332 ms	1.513 ms	1.422 ms	0.073 ms	0%
Paris	4	1.127 ms	1.166 ms	1.150 ms	0.028 ms	0%
Amsterdam	4	0.546 ms	1.032 ms	0.742 ms	0.180 ms	0%
Sao Paulo	4	4.629 ms	4.686 ms	4.657 ms	0.020 ms	0%
Singapore	4	0.742 ms	1.396 ms	0.912 ms	0.281 ms	0%
Sydney	4	0.417 ms	0.699 ms	0.502 ms	0.116 ms	0%
Tokyo	4	2.779 ms	7.191 ms	5.559 ms	1.760 ms	0%

Очевидны два недостатка использования CDN.- Геолокация веб-сайта определяется недостоверно, т.к. идентифицируется IP-адрес ближайшего CDN-сервера, а не реального сервера (это может быть непримлемым для сайта госучреждений)- Несмотря на то, что задержка в масштабах всего мира падает, задержка внутри города расположения веб-сервера может возрастать; например, проверка из города Калуги для калужского сайта bmstu-kaluga.ru при обращении напрямую даёт задержку в 18 мс, но при использовании CDN уже 28 мс.

Задания к лабораторной работе¶

Нагрузочное тестирование веб-сервера с Apache

Для тестирования используются 2 машины – одна с установленным и работающим Apache, вторая будет отсылать запросы и делать выводы о производительности web-сервера.

Тестирование на PHP-запросы:

Тестирование на HTML-запросы:

Провести сравнение результатов и сформировать выводы.

Нагрузочное тестирование веб-сервера с Nginx.

Для тестирования используется 2 виртуальные машины – одна с установленным и работающим Nginx, которой будут отсылаться запросы, другая будет отсылать эти самые запросы и делать выводы о производительности веб-сервера с Nginx.

Примечание

<sudo apt-get nginx> — Установка Nginx

Тестирование на PHP-запросы:

Тестирование на HTML-запросы:

Провести сравнение результатов и сформировать выводы.

Нагрузочное тестирование веб-серверов Apache с балансировщиком нагрузки.

Для тестирования используется 4 машины – две одинаковые с установленным и работающим Apache в качестве веб-серверов, которые соединены с третьей машиной, которая выполняет роль балансировщика нагрузки, на нем работает Nginx, четвертая машина будет отсылать эти запросы серверу и делать выводы о производительности данной связки из балансировщика нагрузки на Nginx и двумя веб-серверами Apache.

Тестирование на PHP-запросы:

Тестирование на HTML-запросы:

Шаг 9 — Настройка сайтов HTTPS с Let’s Encrypt (опционально)

На этом шаге мы настроим сертификаты TLS/SSL для обоих доменов, размещенных в Apache. Мы получим сертификаты посредством Let’s Encrypt. Nginx поддерживает конечные узлы SSL, и поэтому мы можем настроить SSL без изменения файлов конфигурации Apache. Модуль обеспечивает установку в Apache переменных среды, необходимых для бесшовной работы приложений за обратным прокси-сервером SSL.

Вначале мы разделим блоки обоих доменов так, что у каждого из них будет собственный сертификат SSL. Откройте в своем редакторе файл :

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

/etc/nginx/sites-available/apache

Мы используем Certbot для генерирования сертификатов TLS/SSL. Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется.

Прежде всего, добавьте официальное хранилище Certbot:

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

Установите пакет Certbot’s Nginx с :

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

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

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

Далее Certbot запросит желаемый вариант настройки HTTPS:

Выберите желаемый вариант и нажмите . Конфигурация будет обновлена, а затем будет выполнена перезагрузка Nginx для активации новых настроек.

Теперь выполните команду для второго домена:

Откройте один из доменов Apache в браузере с помощью префикса ; откройте , и вы увидите следующее:

Посмотрите раздел PHP Variables. Для переменной SERVER_PORT задано значение 443 и протокол HTTPS включен, как если бы осуществлялся прямой доступ к Apache через HTTPS. При такой настройке переменных не нужно специально настраивать приложения PHP для работы за обратным прокси-сервером.

Теперь отключим прямой доступ к Apache.

Советы по настройке и оптимизации Nginx

Совет №1 – Организация файлов конфигурации Nginx

Обычно файлы конфигурации Nginx хранятся в .

Один из удобных способов организации файлов конфигурации в стиле Debian/Ubuntu Apache:

## Главный файл конфигурации

/etc/nginx/nginx.conf

## Файлы конфигурации вируальных хостов (virtualhost) ##

/etc/nginx/sites-available/

/etc/nginx/sites-enabled/

## Другие файлы конфигурации (если необходимы) ##

/etc/nginx/conf.d/

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

Не забудьте добавить следующие строки в файл :

## Загрузка файлов конфигарации виртуальных хостов ##

include /etc/nginx/sites-enabled/*;

## Загрузка других конфигов из conf.d/ ##

include /etc/nginx/conf.d/*;

Совет №2 – Определить Nginx worker_processes и worker_connections

Настройки по умолчанию хороши, но их стоит немного оптимизировать: .

Базовые настройки Nginx могут обрабатывать сотни одновременных соединений:

1 2	worker_processes 1; worker_connections 1024;

Обычно 1000 одновременных соединений на один сервер это хорошо, но порою другие части, например жесткий диск могут оказаться медленными и это приведет к тому, что Nginx будет заблокирован на операции ввода-вывода (I/O). Чтобы избежать блокировки используйте, например, следующие настройки: :

Worker Processes

1	worker_processes = ;

Чтобы определить сколько ядер имеет ваш процессор, введите:

$ cat /proc/cpuinfo | grep processor

processor : 0

processor : 1

processor : 2

processor : 3

В данном случае у меня четыре ядра, поэтому окончательный парамерт устанавливаем как 4:

1	worker_processes = 4;

Worker Connections

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

Окончательные настройки выглядят седующим образом:

1	worker_connections 1024;

Совет №3 – Скрыть токены Nginx / Скрыть номер версии Nginx

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

1	server_tokens off;

Совет №4 – Ограничение на размер передаваемых данных сервером Nginx

1 2	client_max_body_size 20m; client_body_buffer_size 128k;

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

Совет №5 – Управление кешем для статических файлов

Кэш браузера сохранит ресурсы и пропускную способность вашего сервера. Это несложная настройка Nginx позволит выключить ведение логов ( и ), и установить срок истечения заголовка в 360 дней.

location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {

access_log off;

log_not_found off;

expires 360d;

}

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

Совет №6 – Проксируйте PHP запросы к PHP-FPM

Вы можете использовать по умолчанию стек или соединение через Unix-сокет. Также необходимо установить PHP-FPM слушать точно такой же или Unix-сокет. Вот очень простой пример конфигурации (вариант с Unix-сокетом закоментирован):

# Pass PHP scripts to PHP-FPM

location ~* \.php$ {

fastcgi_index index.php;

fastcgi_pass 127.0.0.1:9000;

#fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;

}

Это дает возможность запуска PHP-FPM другим сервером.

Совет №7 – Предотвращение (запрет) доступа к скрытым файлам

Это очень распространено, когда корень сервера или другие публичные каталоги имеют скрытые файлы, которые начинаются с точки (.) И, как правило, они не предназначены для пользователей сайта. Публичный каталог может содержать файлы системы контроля версий: , ; файлы IDE: ; файлы. Настройки запещают доступ к скрытым файлам и отключают ведение логов:

location ~ /\. {

access_log off;

log_not_found off;

deny all;

}

Что такое Nginx?

Они говорят, что потеря в чужой выгоде. Это именно то, что произошло. Могучий статус Apache был поражен его потенциальным соперником Nginx. Nginx — одна из первых среди ранних претендентов на получение всемирного признания, также является надежной платформой веб-сервера, предназначенной для обслуживания современных веб-запросов. Nginx, разработанный российским разработчиком Игорем Сысоевым, является бесплатным HTTP-сервером с открытым исходным кодом, который также может использоваться как обратный прокси, почтовый прокси и общий прокси-сервер TCP / UDP. Он ориентирован на обслуживание большого количества одновременно работающих пользователей и с минимальными ресурсами. В то время, когда обработка массивного веб-трафика была совершенно невозможной, Nginx пришел на помощь.

Хотя Nginx не может конкурировать с многофункциональным Apache на многих фронтах, его асинхронный статус и однопоточная архитектура делают его разумным выбором по сравнению с Apache. Администраторы часто предпочитают его ресурсоэффективность, легкую архитектуру и высокий уровень параллелизма. И самое главное, он может быть развернут как автономный HTTP-сервер для улучшения архитектуры веб-сервера с использованием минимальных ресурсов. Плюс его способность быстро и эффективно обслуживать статический трафик с ограниченными аппаратными ресурсами не имеет себе равных. Кроме того, Nginx также может быть потенциальным амортизатором, который защитит серверы Apache от внезапных всплесков трафика и уязвимостей безопасности. Короче говоря, Nginx предоставляет все основные функции HTTP-сервера, не жертвуя способностью обрабатывать несколько запросов с ограниченными аппаратными ресурсами.