Обработка жалоб - это всегда ручная работа для саппорта хостинга
Поэтому при большом потоке жалоб рано или поздно Вы надоедаете хостеру
Счёт выставляется так, чтобы потом оплата была за календарный месяц, т.е. с 1 по 31 (за март)
Если у Вас до этого сервера были оплачены до 16 марта, то счёт и будет за 15 дней
С мая месяца будет полная стоимость
auditd демон собирает информацию подобную информацию
Работает на низком уровне
А скрипт while true - всё равно есть вероятность того, что какой-то процесс успеет отработать между циклами (например диск перегружен и долго будет записываться в лог)
Есть ли в этом смысл, если Nginx по сути отдает заранее подготовленные закешированные html страницы клиенту? Ну по сути какой бы режим не стоял Nginx отдает готовый контент, заранее сгенерированный PHP в html.
Если контент статичный, то настройте кеширование на стороне nginx
https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache
В таком случае раздавать кеш будет nginx, и до бекенда вообще не будет доходить запрос (не важно php-fpm, fastcgi и т.д.)
Самое интересное, что он будет бесконечно требовать увеличение параметров. Поэтому я лично уже много лет им не пользуюсь т.к. легче понять как это всё работает, чем бесконечно смотреть на информацию от этого скрипта, которая в 90% вообще бесполезная и просто мусор.
Я про это и говорил, что нет верхнего предела по предлагаемым лимитам
Использовать инструмент можно разве что как удобное представление популярных параметров, для новичка
Тюнер учитывает только работу mysql (а на сервере ещё могут быть php, apache и т.д., которым тоже нужна RAM), к тому же значения там увеличиваются и до терабайта RAM
Вот только если у Вас баз на 10 Мб, какой смысл выделять буферы десятки гигабайтов
Советую гуглить параметры, которые предлагает менять тюнер, и уже самостоятельно рассчитывать значения
Просто копировать рекомендации тюнера - плохая идея
При аренде выделенного сервера никакие порты не могут быть заблокированы.
Порт может быть заблокирован не только на сервере, но и на оборудовании после сервера (коммутаторы, маршрутизаторы и т.д.)
Я в первом посте поинтересовался почему нет nginx + php-fpm на шаред хостинге. Все кто хотел высказался. Теперь более-менее понятно. Да, лучше для такой конфигурации ВПС с возможностью править конфиг. Но если не нужно этого делать часто, то ведь можно и так использовать (с основными настройками). Такие монстры как вордпресс наверное будут быстрее работать, если код уже скомпилирован? А сколько сайтов на этой цмс размещено на шаред хостингах?
php движок одинаково будет работать (сама работа php), в разных режимах
mod_php, lsapi, php-fpm, php-fcgi и т.д. - это всего лишь обёртки/SAPI к движку php
Разница во времени обработки (точнее передачи запроса nginx -> apache -> API или nginx -> php-fpm) можно сказать на уровне погрешности, разница будет в сотые/тысячные доли секунды
Поэтому я бы на этом не акцентировал внимание, что php-fpm - быстрее
Основное преимущество php-fpm, это экономия памяти, так как кроме php больше ничего не запускается, а Apache запускает ещё свои модули (access, auth, mime, proxy, header и.т.д)
Но опять же в рамках шаред хостингов, где ставят сотни гигабайт RAM - экономить на RAM нет смысла, а клиенту приятно работать с .htaccess, не дёргая на каждый чих - ТП хостинга
Понятно. Вопрос закрыт. Для шаред только nginx+apache (с модулем php), для впс можно так или nginx+php-fpm.
Верно
Можно и на шареде сделать nginx + php-fpm, но это нужно создавать "шаблоны" nginx конфигураций под разные CMS, и у клиента спрашивать, какая CMS будет установлена
Возможно я не так выразился.
Вот выше написали, что апаче нужен для того, чтобы " динамически позволяет без перезагрузки управлять роутингом и рядом настроек ".
С помощью того, что Вы указали можно организовать работу шаред хостинга без апаче так, чтобы и была возможность делать настройки nginx и ничего не сломать?
Нет, Ваш вопрос был про перенаправление на бекенд и раздачу статики nginx'ом
Вот на него я и ответил
