ispCP & nginx

[koffu]

А вообще кто-то знает как избавиться от "directory mount point" или сделать не редирект, а со-домен при создании алиаса???

[data-stream_ru]

Ни чег не понял. Это к чему?

[GioMac]

OMG,

Ребята, а вы уверены что это (сабж) вообще надо или нужно? ИМХО лучше оптимизацию представителя племени индейцев (Apache) прочитать, apache worker довольно даже лучшие чем nginx работает, не говоря о других плюсах вроде девелопмент процесса, не говоря о lighttpd.

[marchaos]

Я им о том же. Не верят.

[GioMac]

Я сначала тоже так "думал", вроде было логично - "не зря-же авторы старались и давали описание", хорошо что проверил, сначала переехал на ligttpd, тогда он еще баговым был и быстро от него отказался, потом дергал недоработанный nginx. После трехмесячных булых экспериментов на статике по имиджхостингу который отключил несмотря на то что даже после двухлетнего отруба у мена 20% запросов не улетели а еще беспокоят - πришлось IP добавить т.к. количество соединений было офигенным, так что хватило на опыт. Оказалось что worker лучше и там, даже если взять его в виде фронтенда для php, а что такое статика? Статика это на %2 больше памяти и CPU, да ну его к черту... CPU при фронтенде nginx даже при перенаправлений на динамику больше жрет естественно. Даже лень дергать стандартные конфиги. Лучше даже кэшированием занятся...

Вобщем, идея бестолковая ИМХО, я бы почитал, тем более смотрю что у ребят трафика на эксперименты хватает

Кстати, Apache не нравится тем кто на него с 1.3 переехал, ребята, там просто prefork естьм default, смените его, а если нужен php модуль - перекомпилируете на ZTS, будет работать на 5. Да и не забывает про ненадожность такой модели как и в apache, так и на nginx, lighttpd.

Желаю всем успехов! Тут мне больше нечего вас беспокойть

[koffu]

(03-16-2010 08:19 AM)GioMac Wrote:  Статика это на %2 больше памяти и CPU, да ну его к черту... CPU при фронтенде nginx даже при перенаправлений на динамику больше жрет естественно. Даже лень дергать стандартные конфиги. Лучше даже кэшированием занятся...

Вобщем, идея бестолковая ИМХО, я бы почитал, тем более смотрю что у ребят трафика на эксперименты хватает

Дело даже не в этом, с помощью данной связки есть возможность не только распределить нагрузку по нескольким серверам, а и ограничить по-зонам кол-во запросов в секунду и кол-во соединений, отсюда и меньшая загрузка. Эту схему уже опробовали многие хост-провайдеры и почему-то остановились только на ней, а не на обвязке индейца ещё десятком модулей, чтобы сделать то-же самое. А если вы ещё и кеширование включите, то получите прирост в кол-ве одновременных активных пользователей на джумла сайтах в 10 раз больше.
Для статистики, делал бенчмарк с помощью siege на сайте клиента - сервер Ubuntu, apache-prefork из репов, XCache, 256 RAM, VPS под Hyper-V на 8 x XEON 2,33 - при 10 параллельных сессиях, сформированных из его-же access.log начиналось резкое увеличение времени ответа, при 15 сервер падал в краш из за нехватки памяти. После установки этой схемы то-же начиналось уже к 100 сессиям. После установки php-fcgi вместо апача те-же цифры только за 150 сессиями.

Так что давайте мы не будем искать причины, почему мы что-то не можем сделать. У связки есть множество плюсов, из минусов - нужно что-то делать, чтобы заработало. Если у вас есть аргументированный вариант конфигурации apache с этой-же целью и получения близких или лучших результатов - пожалуйста поделитесь, возможно, мы действительно занимаемся ерундой.
А траффика у нас всегда хватает))

[data-stream_ru]

гуглим по ключам производительность & "nginx + php-fpm"
и
сравнение & "nginx + php-fpm"
мне попадалось много красноречивых статей с графиками...

[GioMac]

(03-18-2010 10:19 PM)koffu Wrote:  

(03-16-2010 08:19 AM)GioMac Wrote:  Статика это на %2 больше памяти и CPU, да ну его к черту... CPU при фронтенде nginx даже при перенаправлений на динамику больше жрет естественно. Даже лень дергать стандартные конфиги. Лучше даже кэшированием занятся...

Вобщем, идея бестолковая ИМХО, я бы почитал, тем более смотрю что у ребят трафика на эксперименты хватает

Дело даже не в этом, с помощью данной связки есть возможность не только распределить нагрузку по нескольким серверам, а и ограничить по-зонам кол-во запросов в секунду и кол-во соединений, отсюда и меньшая загрузка. Эту схему уже опробовали многие хост-провайдеры и почему-то остановились только на ней, а не на обвязке индейца ещё десятком модулей, чтобы сделать то-же самое. А если вы ещё и кеширование включите, то получите прирост в кол-ве одновременных активных пользователей на джумла сайтах в 10 раз больше.
Для статистики, делал бенчмарк с помощью siege на сайте клиента - сервер Ubuntu, apache-prefork из репов, XCache, 256 RAM, VPS под Hyper-V на 8 x XEON 2,33 - при 10 параллельных сессиях, сформированных из его-же access.log начиналось резкое увеличение времени ответа, при 15 сервер падал в краш из за нехватки памяти. После установки этой схемы то-же начиналось уже к 100 сессиям. После установки php-fcgi вместо апача те-же цифры только за 150 сессиями.

Так что давайте мы не будем искать причины, почему мы что-то не можем сделать. У связки есть множество плюсов, из минусов - нужно что-то делать, чтобы заработало. Если у вас есть аргументированный вариант конфигурации apache с этой-же целью и получения близких или лучших результатов - пожалуйста поделитесь, возможно, мы действительно занимаемся ерундой.
А траффика у нас всегда хватает))

Вроде так, просто забудьте префорк

[data-stream_ru]

Про воркер писали что нестабильная штука по определению. Один сбойный процесс может подвесить весь сервер.
Но конкретно не скажу, умну воркер не пошёл. Какой то библиотеки ему не хватило. Гуглил-гуглил, так и не нагуглил где взять.

А как в воркере организовывать пхп?

[data-stream_ru]

При установки из репозитариев апач по дефолту ставится в префолке. Модуль libphp5-zts.so отсутствует. При компиляции ручками всё нормально.