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

[Anatoly Matyakh]

On Tue, 02 Oct 2007 17:31:07 +0300, Gena Makhomed  
<makhomed at pbank.lutsk.ua> wrote:

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

Процесс процессу рознь.
Мелкие ничего не делающие демоны сервер не грузят, как равное количество
пыхтящих форков апача. CGI запускаются раз в пятилетку, а этот бэкенд  
отрабатывает
только CGI, и только в vhost/cgi-bin.

К тому же это простейшее решение, фактор лени: довольно легко пересобрать  
mini_httpd,
пропатчив на предмет uid, или выбрать другой минисервер (thttpd чем  
плох?)...

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

> разве не будет тут более оптимальным использовать
> в качестве backend`а apache2 --with-mpm=worker ?

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

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

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

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

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

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

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

-- 
IT Philosopher