ru.cgi.perl

 
 - RU.CGI.PERL ------------------------------------------------------------------
 From : Artem Chuprina                       2:5020/400     22 Feb 2002  22:43:27
 To : "Nelly Sadretdinova"
 Subject : Re: FastCGI
 -------------------------------------------------------------------------------- 
 

 Здравствуй, Nelly Sadretdinova.
 
 NS> Интересно, по опыту других - дейтсвительно ли сабж убыстряет работу скрипта
 NS> и уменьшает загрузку сервера?
 NS> По моему личному опыту, при большой посещаемости сервера (30-40 посетителей
 NS> единовременно) - вроде бы помогает, по крайней мере число процессов в памяти
 NS> сокращается. А с другой стороны - дополнительные глюки возникают, не всегда
 NS> обнуляются почему-то локальные переменные.
 
 Действительно. Hо реально - под нагрузкой (30-40 посетителей одновременно -
 это нижняя граница понятия "под нагрузкой"). Дополнительные глюки могут
 возникать только если скрипт неаккуратно написан. Это общее место всех таких
 конструкций. Скрипт внутри такой конструкции оформляется как функция и живет
 долго, так что рассчитывать на то, что по завершении скрипта система что-то
 там почистит, нельзя. Как правильно посоветовал Витус, почитать mod_perl_trap
 из комплекта mod_perl и творчески применить результат.
 
 NS> Ести ли какие-либо другие альтернативы для Perl'а при высоком уровне
 NS> посещаемости?
 
 Если узкое место действительно в Perl, то либо FastCGI, либо mod_perl. Вроде
 бы по тестам местных обитателей они сравнимы. Часто еще узкое место бывает в
 том, что скрипт-то отработал бы быстро, но поскольку канал до юзера узкий, то
 отдает он данные медленно и не может переключиться на следующий запрос.
 Вернее, засада-то у апача, но поскольку что при mod_perl, что при FastCGI
 поднимается по одному экземпляру perl на каждого ребенка апача, а память не
 резиновая, начинается своппинг. В таких ситуациях очень помогает
 httpd-акселератор - прокси-сервер, будь то апач с mod_accel, squid, oops или
 кто еще, поставленный в режим ускорения http-запросов. При этом он принимает
 запрос от юзера, прикидываясь тому именно тем сервером, на который юзер пошел
 (т.е. для юзера все прозрачно), быстро отдает запрос собственно рабочему
 апачу, быстро получает от него ответ (они либо вообще на одной машине
 работают, либо соединены толстым каналом), и медленно начинает отдавать его
 клиенту. Поскольку акселератор умеет немного, то и памяти он занимает
 существенно меньше, чем апач с перлом. А то и на соседнюю машину вынесен. Это
 на самом деле общее решение, к перлу отношения не имеющее.
 
 -- 
 Artem Chuprina
 Communiware.net
 RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/358.49, ICQ: 13038757
 --- ifmail v.2.15dev5
  * Origin: Leninsky 45 home network (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    FastCGI   Nelly Sadretdinova   22 Feb 2002 21:14:52   Re: FastCGI   Artem Chuprina   22 Feb 2002 22:43:27   Re: FastCGI   Nelly Sadretdinova   23 Feb 2002 13:25:36   Re: FastCGI   Artem Chuprina   24 Feb 2002 01:46:56   FastCGI   pavel kurnosoff   25 Feb 2002 01:43:42