Ограничение соединений с бэкэндом

[Gena Makhomed <makhomed@xxxxxxxxxxxxxx>]

Здравствуйте, Anatoly!

Tuesday, October 2, 2007, 6:41:52 PM, you wrote:

>> и в результате получается как минимум по 1 висящему в памяти
>> процессу на каждого пользователя? какая же это экономия...

AM> Процесс процессу рознь.

вот с CGI как раз проблем нет никаких, 1 серверный процесс
может запускать cgi-скрипты для всех клиентов с нужными uid.

проблемы с Fast-CGI. там либо 1 клиент == 1 сервер,
либо все пользователи имеют доступ к файлам друг друга.
(потому что нет настройки php_admin_value open_basedir)

даже если запускать master process php-fpm с правами root -
worker то всеравно будет работать с uid/gid конкретного пользователя,
и если будут одновременно запросы ко всем N сайтам - в памяти окажется
N различных экземпляров php-fpm, как минимум по одному на клиента?
и что будет, если сайтов на хостинге не 20, а 200 или даже 2000 ?

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

php-fpm удобно использовать когда на хостинге размещен
один высоконагруженный сайт, и тогда можно хорошо экономить
ресурсы (память и процессор) не используя "лишний" apache.

AM> Мелкие ничего не делающие демоны сервер не грузят,
AM> как равное количество пыхтящих форков апача.

апач когда ничего не делает - он ведь тоже процессора не ест,
а только занимает оперативную память не-shared частями процесса.

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

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

>> кстати, раньше они могли сами менять конфигурацию своего сайта
>> через .htaccess, сейчас - будут все время дергать support с просьбами
>> поправить какие-то настройки сервера (например, та же basic-авторизация)

AM> В данном случае это несущественно, поскольку этим полтора клиента 
занимались.

>> а какие ресурсы являются более дорогими - процессорное время сервера,
>> или время службы технической поддержки хостинга? имхо все-таки второе.

AM> Так я и написал - это не решение для большого хостинга.
AM> Тут - 20 клиентов, на которых можно откатать модель.

если откатать модель на 20 клиентах и потом применить ее
на 200 / 2000 клиентов, эти проблемы станут существенными.

как эту проблему с постоянной ручной правкой конфига веб-сервера
решать на "большом хостинге" - такой вопрос рано или поздно появится.

AM>>> Большой хостинг так не перенесёшь, поскольку мне пришлось заглядывать
AM>>> во все закоулки, где что-нибудь переопределяли через .htaccess.

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

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

AM> Так если давать панель управления хостингом, о каких .htaccess речь?
AM> Выносить функциональность подстройки в панель - и пускай управляют,
AM> вот и саппорт дёргать не будут, и в синтаксисе не ошибутся.

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

-- 
Best regards,
 Gena                            mailto:makhomed@xxxxxxxxxxxxxx