Nginx количество одновременных соединений

С таким запросом к нам обратился Михаил.  У него на виртуальном сервере десяток сайтов, суммарным трафиком около 2к хостов в сутки.  И VPS с минимальным  тарифом у хостера с 1 гб  оперативной памяти, одним ядром CPU и 20 Gb SSD.  Сайты на WordPress.   На сервере кроме этого также стоит панель управления хостингом ISP Manager Lite 5.

Вопросы аппаратного обеспечения

Оптимизируя нашу систему, мы не можем выделить достаточно, уделяя должное внимание настройке нашего оборудования. Какое бы из этих решений мы ни выбрали для нашей установки, наличие достаточного объема ОЗУ имеет решающее значение. Когда процесс веб-сервера или интерпретатор, такой как PHP, не имеют достаточно оперативной памяти, он начинает подмену, и подкачка эффективно означает использование жесткого диска для пополнения оперативной памяти. Результатом этого является увеличение задержки каждый раз, когда к этой памяти обращаются. Это подводит нас ко второму пункту — месту на жестком диске. Использование быстрого SSD-хранилища является еще одним критическим фактором скорости нашего сайта. Нам также необходимо учитывать доступность ЦП и физическое расстояние центров обработки данных нашего сервера до предполагаемой аудитории.

Чтобы глубже погрузиться в аппаратную сторону настройки производительности, у Dropbox есть хорошая статья .

Настройки Apache

Тут от настроек не так много, главное установить нужный порт и настроить видимость сервера только внутри себя. Порт 80 мы использовать больше не можем, так как им будет пользоваться nginx поэтому возьмем порт 81.

Редактируем файл /etc/httpd/

#ставим внутренний адрес и меняем порт на 81 Listen 127.0.0.1:81 #KeepAlive запросы позволяют устанавливать постоянные соединения между клиентом и сервером. Это экономит ресурсы на отсутствии повторной установки соединений. KeepAlive Off

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

Создаем виртуальный хост для нашего сайта с минимальными настройками. Это может быть общий файл  или на каждый сайт свой файл.

# Указываем выбранный порт: <VirtualHost 127.0.0.1:81> ServerName ServerAlias DocumentRoot /home/www/html/site CustomLog /var/log/httpd/_ combined ErrorLog /var/log/httpd/_ <Directory «/home/www/htmlsite»> AllowOverride none </Directory> </VirtualHost>

Директива AllowOverride включает использование файла .htaccess. В этом случае при каждом запросе Apache будет обращаться к директории сайта для его поиска. Лучше переместить все настройки в конфигурационный файл немного ускорив обработку.

 Включаем gzip nginx

Давайте приступим к настройке. Ускорять мы будем следующия способом – включим сжатие файлов GZIP, и кэширование в браузере. Этого от нас очень хочет великий гугл. Проверить что он хочет, можно здесь – PageSpeed Insights. Говорят, что ранжирование сайта не в последнюю очередь зависит от скорости его работы.

 Включаем gzip nginx

Включим сжатие gzip непосредственно на nginx. Это значит что перед отправкой нам, сервер будет сжимать статические данные в архив, а браузер распаковывать на лету. За счет этого удается добиться сокращения передачи трафика по сети до 80%.

Включать в данном случае директивы mod_gzip или mod_deflate в .htaccess (или ) в apache бессмысленно – apache не отдает нам статику, ему нечего будет сжимать.

 Включаем gzip nginx

Переключим сервер в ручной режим работы (предварительно включив нужные модули)

Подключимся по протоколу SSH, с помощью утилиты PUTTY к серверу.

 Включаем gzip nginx

Открываем конфиг nginx /home/ИМЯ/etc/nginx/

В контексте http { … } вставляем следующий код:

 Включаем gzip nginx

#включение/выключение gzip on; #оставляем по умолчанию gzip_buffers 16 8k; #Степень сжатия, макс.9 gzip_comp_level 6; #Разрешает отдавать сжатый контент проксирующим серверам gzip_proxied any; #Минимальная величина ответа (Content-Length) для сжатия в байтах gzip_min_length 1024; #Типы файлов, которые будут сжиматься gzip_types application/xml text/css text/js text/xml application/x-javascript text/javascript application/javascript application/json application/xml+rss; #минимальная версия протокола gzip_http_version 1.0; #Важный параметр, помогает браузеру получить нужный кэш с промежуточного прокси сервера gzip_vary on;

Читайте также:  Apple выпустила iOS 11 beta 2 для iPhone, iPad для разработчиков

Комментарии можно удалить. Данные параметры будут действовать для всех сайтов на виртуальном хостинге.

 Включаем gzip nginx

Документация на русском по nginx – 

Проверить, что сжатие работает, можно на этих сайтах –  и 

Предварительное сжатие

Перед тем, как отдать содержимое страниц в браузер посетителя, можно его сжать. Сжатие уменьшает размер передаваемых файлов (иногда в несколько раз), что приводит к увеличению скорости загрузки страниц и уменьшению исходящего трафика. Сжимать нужно только файлы, содержащие текстовую часть — текст, HTML, PHP, JS, XML, и прочие подобные. Текст хорошо сжимается даже при низком уровне компрессии, объем передаваемых фалов уменьшается на 50-80%. Конечно, файлы небольшие, всего десятки килобайт, но если учесть, что таких фалов тысячи, и загружаются они тысячами посетителей каждый день, то, как говорят, с миру по нитке — нищему на воротник, экономия получается существенная.

Предварительное сжатие / Apache

Для тех, у кого установлен Apache, нужно узнать у хостера, какие специальные модули, реализующие его, установлены — mod_pagespeed или mod_deflate? Обычно в Apache 2x устанавливают mod_deflate. Есть еще mod_gzip, но его устанавливали в предыдущих версиях, так что его встретить маловероятно.

Если установлен модуль mod_pagespeed, то в файл .htaccess, находящийся в корне вашего сайта, нужно вставить:

ModPagespeed on # using commands,filters etc

Если установлен модуль mod_deflate, то то в файл .htaccess, находящийся в корне вашего сайта, нужно вставить:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript

В данном случае сжатию подвергаются все текстовые файлы — txt, html, xml, xhtml, css, js.

Предварительное сжатие / Nginx

Если хостинг работает под управлением Nginx, то директивы будут выглядеть иначе. В файл .htaccess, находящийся в корне вашего сайта, нужно вставить:

server { gzip on; gzip_types text/html text/css application/x-javascript text/plain text/xml image/x-icon; }

Предварительное сжатие / Скрипт

Бывает так, что сервер, обеспечивающий работу вашего блога, не поддерживает mod_deflate или mod_gzip. В этом случае можно прибегнуть к универсальному скрипту, который работает и на Apache, и на Nginx.

В файл используемой вами темы, в самое его начала, первой строкой нужно вставить:

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

Как использовать WTotal Cache с PHP 7

Если у вас есть проблема несовместимости W3 Total Cache и PHP версии 7, то обновите плагин до последней версии.

Вы могли получить такую ошибку:

Warning: Parameter 1 to W3_Plugin_TotalCache::ob_callback() expected to be a reference, value given in -includes/ on line 1234

Или вы не получали ошибку, но W3 Total Cache перестал сохранять изменения и кешировать сайт. Если вы посмотрите в код страницы в режиме Debug, то увидите, что служебные комментарии W3TC не добавляются.

Так или иначе, эта проблема была решена в плагине версии 0.9.5, обновите плагин до последней версии, сейчас это версия 0.9.5.4. На этом сайте работает W3TC этой версии и установлена PHP версии 7.1, никаких проблем нет, все работает нормально.

Если проблема все еще есть, напишите в комментариях, есть инструкция по решению этой проблемы.

Суть решения в том, чтобы либо вернуться на PHP 5.6, либо изменить &$buffer на $buffer в нескольких файлах на сервере. В этом случае после обновления плагина эти изменения будут заменены новой версией файлов.

Другие способы

Установи правильные значения системных переменных

Открой файл /etc/ и помести в него следующие строки:

# Защита от smurf-атак _echo_ignore_broadcasts = 1 # Защита от неправильных ICMP-сообщений _ignore_bogus_error_responses = 1 # Защита от SYN-флуда _syncookies = 1 # Запрещаем маршрутизацию от источника _source_route = 0 _source_route = 0 # Защита от спуфинга _filter = 1 _filter = 1 # Мы не маршрутизатор _forward = 0 _redirects = 0 _redirects = 0 # Включаем ExecShield = 1 _va_space = 1 # Расширяем диапазон доступных портов _local_port_range = 2000 65000 # Увеличиваем максимальный размер TCP-буферов _rmem = 4096 87380 8388608 _wmem = 4096 87380 8388608 _max = 8388608 _max = 8388608 _max_backlog = 5000 _window_scaling = 1

Читайте также:  Как просматривать и редактировать файлы PDF в Linux?

Размести корневой каталог Web-сервера на выделенном разделе

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

/dev/sda5 /nginx ext4 defaults,nosuid,noexec,nodev 1 2

Помести nginx в chroot/jail-окружение

Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.

Установи правила SELinux для защиты nginx

Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx () были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:

# tar -zxvf se-ngix_1_0_ # cd se-ngix_1_0_10/nginx # make # /usr/sbin/semodule -i

Настрой брандмауэр

Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.

Ограничь количество соединений с помощью брандмауэра

Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:

# iptables -A INPUT -p tcp —dport 80 -i eth0 -m state —state NEW -m recent —set # iptables -A INPUT -p tcp —dport 80 -i eth0 -m state —state NEW -m recent —update —seconds 60 —hitcount 15 -j DROP

Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:

Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.

Настрой PHP

Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/ защищенного сервера:

# Отключаем опасные функции disable_functions = phpinfo, system, mail, exec # Максимальное время исполнения скрипта max_execution_time = 30 # Максимальное время, которое может потратить скрипт на обработку данных запроса max_input_time = 60 # Максимальное количество памяти, выделяемое каждому скрипту memory_limit = 8M # Максимальный размер данных, отсылаемых скрипту с помощью метода POST post_max_size = 8M # Максимальный размер загружаемых файлов upload_max_filesize = 2M # Не показывать ошибки PHP-скриптов пользователям display_errors = Off # Включаем Safe Mode safe_mode = On # Включаем SQL Safe Mode _mode = On # Позволяем выполнять внешние команды только в этом каталоге safe_mode_exec_dir = /путь/к/защищенному/каталогу # Защищаемся от утечки информации о PHP expose_php = Off # Ведем логи log_errors = On # Запрещаем открытие удаленных файлов allow_url_fopen = Off

Настройка конфигурации

Root-каталог Nginx по умолчанию находится в директории /usr/share/nginx/html. Все файлы, которые размещаются в нем, автоматически обслуживаются веб-сервером. Место определяется файлом конфигурации, который можно найти в /etc/nginx/conf.d/

Новые блоки server создаются через конфигурационные файлы в /etc/nginx/conf.d. Они буду загружаться при запуске Nginx, если заканчиваются на .conf.

Читайте также:  Обзор AirPods Pro: стоит ли покупать для Android?

Основной конфигурационный файл сервера находится в /etc/nginx/ Через него изменяются любые настройки.

Кэширование прокси-сервера Nginx

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

И это последнее, что не всегда 100% ясно, когда вы jr dev или только начинаете в этом мире кодирования.

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

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

Кэш-память Nginx

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

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

По этой теме мы попытаемся объяснить, что Кэш-память Nginx и как вы можете ускорить работу своих веб-приложений.

Что такое прокси-кэш?

Кэш-прокси – это в основном данные, хранящиеся на промежуточном сервере между клиентом и конечным сервером.

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

Как включить кеш-сервер Nginx?

Чтобы включить прокси-кеш, вам нужно отредактировать файл и установить две важные переменные:

  • proxy_cache_path: путь, в котором вы будете хранить данные кэширования, в том месте, где вы будете настраивать настройки кеша.
  • proxy_cache: директива, используемая для активации кэша прокси.
Кэширование прокси-сервера Nginx

Пример полнофункциональной конфигурации прокси-кеша:

proxy_cache_path / var / nginx / cache levels = 1: 2 keys_zone = app_cache: 10m max_size = 5g неактивный = 45m use_temp_path = off; server {… … location / products {proxy_cache app_cache; proxy_pass http: // app_upstream; } … …}

Давайте объясним каждый использованный нами вариант:

proxy_cache_path / var / nginx / cache levels = 1: 2 keys_zone = app_cache: 10m max_size = 5g неактивный = 45m use_temp_path = off;

/ Вар / Nginx / кэш / – это выбранный каталог для хранения данных кеша, вы можете установить любой каталог по своему усмотрению.

Уровни = 1: 2 задает двухуровневую иерархию каталогов в / var / nginx / cache. Это полезно, когда у вас очень много кешированных файлов, чтобы избежать медленных скоростей во время доступа к файлам.

keys_zone = app_cache: 10m определяет зону общей памяти 10M, в которой будут храниться ключи кеша и информация метаданных. Это помогает ускорить проверку прокси-кешей.

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

неактивный = 45m является лимит срока хранения для неактивного содержимого, он указывает, как долго кешированный элемент может оставаться в кеше без доступа. Если в течение последних минут 45 файл не доступен, он будет удален из кеша.

use_temp_path = выкл устанавливает временную директорию в off, это означает, что Nginx будет записывать временные файлы, используемые для кеша, в тот же каталог, который ранее был указан в переменной proxy_cache_path (/ var / nginx / cache в этом случае). Чтобы избежать ненужных операций ввода-вывода, мы отключили его.

proxy_cache позволяет кэшировать все содержимое, размещенное под блоком местоположения, в этом случае было задано как «location / products», но вы можете поместить его для кэширования всего содержимого вашего веб-сайта, например:

место нахождения / { proxy_cache app_cache; proxy_pass http: // app_upstream; }

Я не хочу кэшировать некоторые объекты, что я могу сделать?