Lite.Host - хостинг для тех, кто любит не переплачивать

Так можно делать тогда, когда эти модули собраны как отдельные библиотеки. Мы так делать не будем, так как это может снизить общую производительность за счет необходимости подгрузки каждого модуля по отдельности (один бинарник стартует быстрее).

Что-то мы делаем по разному. Настройки пользователя https://yadi.sk/i/CnCmA9DZ03VBEw , настройки домена https://yadi.sk/i/rZGF3T9FNspMOw

а что у вас при каждом запросе php "стартует"? хотя если через .htaccess, то похоже да... :(

а opcache тогда как? вообще получается не работает или в файлах хранится?

у меня к примеру apache и php собираются максимально пустыми.

каждый юзер может конфигом и php.ini добавить нужные модули в обоих.

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

аналогично php-fpm, тоже висит несколько процессов у каждого на готове всегда.

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

плюс, so (shared object) для того и придумали, чтобы можно было загрузить в память этот "кусок" в одном экземпляре и потом его же совместно использовать могли еще куча процессов. т.е. ради экономии памяти.

вот смотрю допустим php7.3 - 20мб php сам весит и к нему идет пол сотни .so'шек на 40мб.

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

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

но минус в том что сейчас только 1 версия php на аккаунт. и только одна опция - либо apache/php, либо php-fpm.

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

по опыту, одной версии на аккаунт хватает за глаза 99% народу.

Когда к сайту нет запросов долгое время, то все PHP процессы завершаются с целью экономии оперативной памяти. Поверьте, это отличный вариант скорости и экономии памяти при размещении большого числа сайтов на одном сервере. opCache при этом чувствует себя хорошо.

Провел эксперимент на тестовом сайте http://wp.pluton-host.ru с WordPress:

Холодный старт около 600 мс: https://yadi.sk/i/oXacvkwRC90ctw

Последующие ответы около 15-20 мс: https://yadi.sk/i/8lmMqxHGGmh0YA

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

Обычный пользователь WordPress (и прочих систем) не хочет разбираться в модулях и прочих вещах, он хочет работающий сайт с поддержкой максимального числа плагинов . К слову, некоторые его даже установить не могут из панели в несколько клиентов, по этой причине у нас можно выбрать установку сразу в форме заказа.

---------- Добавлено 21.10.2019 в 22:04 ----------

Еще есть вот такая штука https://docs.cloudlinux.com/cloudlinux_os_components/#criu-support , но так как она до сих пор в бете, то не используем её. Она как раз снижает задержку при старте + не держит процессы в памяти.

Да ну

criu давно в prod

lsapi подавно

Вы что-то явно путаете

и большой разницы не увидит пользователь в скорости обработки php как один большой бинарник или куча so'шек

LSAPI действительно давно в production, используем с 2015 года.

С CRIU действительно ошибся, сейчас он есть в ветке production. Смотрел его в начале прошлого года, тогда ставил из ветки для тестирования. Исходя из подписки на новости CloudLinux, первое упоминание в стабильной ветке появилось в марте 2018 года

Цифр не приведу, но перспектива постоянного подключения пачки so файлов выглядит так себе. Не вижу смысла выделять популярные модули so файлы. За все годы работы никто не просил отключать какие-либо модули, только подключать :)

Эмм.. загрузка и производительность вещи несколько разные. Мне кажется можно пожертвовав долей сек на загрузку (и то скорее всего "жертв" никаких не будет ) для того, чтобы не загружалось, не болталось в памяти и не отъедали ресурсы кучка ненужного хлама.

Но дело ваше конечно..

Не исключаю. Я делаю так, как позволяет панель. Результат показал.

И настройки перла при этом юзеру тоже доступны, кстати.

И кстати ещё вспомнил. Я вчера пытался запустить node.js и lvе. Так они не запустились (ошибка, обратитесь к хостеру). Мне оно в целом не нужно, но просто ради любопытства покнопал.

Собрал цифры с одного из серверов. В одном случае небольшая экономия памяти, в другом случае старт процессов немного быстрее. Подробные данные по каждой версии и набору модулей https://pastebin.com/Hf9GMDVG

1. Большой бинарник (49M) + 8 SO модулей (11M), суммарно 58 модулей. Процесс в состоянии sleep данным top потребляет 17M RES / 9.9M SHR памяти. Среднее время выполнения 1000 вызовов простейшего скрипта 39.0743 секунд.

2. Маленький бинарник (4.2M) + 29 SO модулей (11M), суммарно 44 модуля. Процесс в состоянии sleep данным top потребляет 15M RES / 8.79M SHR памяти. Среднее время выполнения 1000 вызовов простейшего скрипта 41.274 секунд.

Нужно смотреть из под конкретного пользователя, если будет актуально - пишите в поддержку.

Node.JS не поддерживаем (раздел скрыл в меню), Раздел LVE с уровня реселлера недоступен, а из под пользователя должен отображать статистику потребления ресурсов.

Евгений Русаченко, Ну это же время холодного старта :)

Запущенный lsphp не будет постоянно считывать so'шки

А с criu вовсе всё будет сводиться к считыванию нескольких файлов, с которых будет процесс lsphp восстанавливаться

Тем более сейчас эта технология уже обкатана и основные проблемы устранены

Я понимаю, но так как ранее обсуждали именно скорость и память, я привел цифры :)

CRIU действительно крут, в будущем его тоже будем использовать.

Мне оно зачем? Я вам указал на такой косяк, а захотите разобраться или нет - дело ваше. Мне что-то доказывать не нужно. Читая написанное в топике я уже принял решение.

Так убить преимущества CloudLinux.. Нда. Воистину горе от ума.