URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 15910
[ Назад ]

Исходное сообщение
"OpenNews: Настройка Nginx для поддержки PHP при помощи FastCGI"

Отправлено opennews , 31-Май-06 16:58 
В статье (http://blog.kovyrin.net/2006/05/30/nginx-php-fastcgi-howto/l.../) описывается процесс установки и настройки nginx с поддержкой PHP в режиме FastCGI.

URL: http://blog.kovyrin.net/2006/05/30/nginx-php-fastcgi-howto/l.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=7629


Содержание

Сообщения в этом обсуждении
"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено Евгений , 31-Май-06 16:58 
  причем нахрена это нужно - вопрос открытый.
nginx еще как-то неплохо как внешний прокси и обработчик статики - и то, в дискуссии на форуме недавно писали, что сквид давал бОльшую производительность как прокси для множества медленных клиентов.

"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено Квагга , 31-Май-06 17:24 
Круто, круто...

"сквид, чем нжынкс..."

Да..................................................


"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено Квагга , 31-Май-06 17:26 
Причем уважаю само упоминание в о сквиде в топике
о поддержке PHP в http сервере. Мощно.

"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено smb , 31-Май-06 17:28 
Ну либо apache + mod_php, либо FastCGI-ные php-шные демоны через tcp/unix sockets в ожидании скриптов...

nginx довольно прилично как frontend...
Сквид может дать большую производительность из-за кэширования, имхо...Ибо в остальном nginx(по сути обработки соединений и отдачи файлов) - легкий проксирующий навесок над epoll/kqueue + sendfile, и тут оптимальней ничего быть не может...(сквид кстати epoll/kqueue не юзает)...

поэтому - тесты в студию, что еще можно сказать....


"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено Евгений , 01-Июн-06 12:25 
>Ну либо apache + mod_php, либо FastCGI-ные php-шные демоны через tcp/unix sockets
>в ожидании скриптов...
>
>nginx довольно прилично как frontend...

Вот как фронтенд для апача+мод_пхп я и сравнивал. ты понял, кое-кто - нет. 8_)

>Сквид может дать большую производительность из-за кэширования, имхо...Ибо в остальном nginx(по сути >обработки соединений и отдачи файлов) - легкий проксирующий навесок над epoll/kqueue >+ sendfile, и тут оптимальней ничего быть не может...(сквид кстати epoll/kqueue >не юзает)...
>
>поэтому - тесты в студию, что еще можно сказать....

Были тесты в форуме на www.lexa.ru ..  автор nginx тоже их обсуждал.


"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено smb , 04-Июн-06 01:18 
>Вот как фронтенд для апача+мод_пхп я и сравнивал. ты понял, кое-кто - нет. 8_)
=)

>Были тесты в форуме на www.lexa.ru ..  автор nginx тоже их обсуждал.
=/ Не нашел...


"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено Gorthaur , 02-Июн-06 03:39 
Нгинкс, как веб-сервак живёт и отлично летает. Особенно там, где Апач загибается от кол-ва соединений :)  

"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено Евгений , 02-Июн-06 10:12 
>Нгинкс, как веб-сервак живёт и отлично летает. Особенно там, где Апач загибается
>от кол-ва соединений :)

Я не спорю.  Но в таком вот варианте (легкий сервер или прокси перед апачем для поддержки большого количества медленных соединений) сквид или оопс еще лучше 8)



"Настройка Nginx для поддержки PHP при помощи FastCGI"
Отправлено sdv , 10-Мрт-07 14:37 
>>Нгинкс, как веб-сервак живёт и отлично летает. Особенно там, где Апач загибается
>>от кол-ва соединений :)
>
>Я не спорю.  Но в таком вот варианте (легкий сервер или
>прокси перед апачем для поддержки большого количества медленных соединений) сквид или
>оопс еще лучше 8)


Угу. У сквида есть проблема, ставлю его в реверс прокси для обслуживания нескольких виртуальных хостов, статики больше 4Гб суммарно. Памяти навалом, места полно. Работает 2 месяца потом начинает шуршать диском, значения записи просто запредельные. Очистки кэша\перестановки сквида непомогают. Насколько понял - не только у меня такая проблема.

И второе - вкомпиленное по умолчанию при сборке многих пакетов количество дескрипторов. 1024, этого мало, нужно пересобирать из сорцов.