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

["Anatoly Matyakh" <protopartorg@xxxxxxxxx>]

On Tue, 02 Oct 2007 17:31:07 +0300, Gena Makhomed  
<makhomed@xxxxxxxxxxxxxx> 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