"долгие" php процессы - какая конфигурация лучше (apache/nginx, fastcgi/mod_php)

[Gas]

"долгие" php процессы - какая конфигурация лучше (apache/nginx, fastcgi/mod_php)

Задача:
1. "скрипт" выполняет обращения(soap,rest) к внешним сервисам, ответ может прийти через 5 секунд (ускорить это мы не можем);
2. время обработки полученных данных (до 100KB) - миллисекунды и большой роли не играет;
3. конкурентность запросов, допустим, 100 запросов в секунду;
4. итого: через 5 секунд будет висеть ~500 процессов и будут кушать прилично памяти.

Вопрос: какая конфигурация лучше (по памяти) подойдёт в этом случае?

Мои соображения:
1. nginx+php, как я понял, в данном случае не подойдёт, из-за его архитектуры долгие процессы будут блокировать обработку остальных (у других light-серверов подобная архитектура и ограничения?);
2. apache+fastcgi vs apache+mod_php вкомпиленый статиком - я могу _предположить_ что применительно к данной задаче mod_php может оказаться выгодней.
3. можно как front поставить nginx,etc... от "медленных" клиентов, но клиентами будут не броузеры, а другие сервисы и количество "медленных" среди них не думаю что будет большим.

Кто что думает на этот счёт?

 

[Wicked]

не понял 3е соображение в свете 1й задачи

-~{}~ 06.11.08 01:05:

если придумаешь, как сделать свой скрипт асинхронным, т.е. разбить его пополам:
1) часть до отсылки запроса на внешний ресурс,
2) часть, реагирующая на прием ответа от внешнего ресурса,
... то тебе поможет сетевая многозадачность

 

[Angerslave]

Gas
Смотря во что упрётся всё. Третий вариант предпочтителен для обратной ситуации - быстрые запросы, медленные клиенты. Между первым и вторыми двумя определиться помогут бенчмарки

 

[ys]

Gas

Задача:
1. "скрипт" выполняет обращения(soap,rest) к внешним сервисам, ответ может прийти через 5 секунд (ускорить это мы не можем);

Я так понимаю, это и есть `самое узкое место`.
А нельзя его тупо кэшировать?

 

[Gas]

Wicked

не понял 3е соображение в свете 1й задачи

смысл этого действа такой: наш сервис выступает как прокси к ряду внешних (чужих) сервисов с различными api и форматами результатов, мы приводим всё в унифицированный формат.
Грубо говоря (только пример), получение погоды для разных городов с разных метео-сайтов, разные пользователи запрашивают погоду для разных мест. У нас это не города и количество возможных параметров очень большое чтоб периодически получать все возможные результаты и отдавать только из кеша.

если придумаешь, как сделать свой скрипт асинхронным, т.е. разбить его пополам:

думал об этом, скорее всего будет и асинхронный режим работы, но синхронный тоже хотелось бы.

ys

А нельзя его тупо кэшировать?

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


Angerslave

Смотря во что упрётся всё.

в cpu и диски не упрётся, точно в память и может в сеть (хотя сомнительно).


В принципе вопрос сожно перефразировать так: у какой связки webserver+php меньше оверхеда по памяти при одинаковых php extensions и минимальном количестве модулей к серверу, в свете озвученной специфики задачи.

Если это вопрос про сферического коня, тогда чёрт с ним, буду решать проблемы - по мере их возникновения

 

[флоппик]

у какой связки webserver+php меньше оверхеда по памяти при одинаковых php extensions и минимальном количестве модулей к серверу

Ну, родной FastCGI большого смысла не имеет, в свете принципов его работы в PHP.
Я бы все же поглядел в php_fpm ?
Там кстати есть еще fastcgi_finish_request() — имхо, он тебе бы пригодился.

 

[Gas]

Я бы все же поглядел в php_fpm ?

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

fastcgi_finish_request

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

 

[флоппик]

Проблема как всегда в PHP. Он не держит tread-safe, а значит Апач2 с его mpm — бесполезен, и не держит настоящий FastCGI, так что обычно php_fpm спасает