ну http разбирать вы можете, но задача будет намного более сложная + вы теряете весь мощный инструментарий веб сервера который уже имеется (выстраивание в очереди и т.п.)
да не кстати у меня демоны которые парсили кучу данных работали месяцами и ничего так и не было там утечек особо (ну за 2 месяца 12 метров набежало на 20 процессов — смешно и в рамках погрешности) да и перезапуск не дорогая процедура. а так писать просто аккуратно если то и GC не нужен
смотрите сама возможность создания стека становится возможной благодаря тому только что есть непрерывно работающий воркер который в конце работы не должен скидывать статистку.
PS. Вы (Nascosto) для себя как я уже вижу все решили и не слушаете аргументы других людей, поэтому не вижу необходимости вас в чем либо убеждать далее. Если вам выпадет удачный случай сделать что либо действительно высоконагруженное, то вы оцените все преимущества, а так для вас это все очевидно чужое и не понятное.
все просто идеалогия fastcgi такова:
работает процесс постоянно ему иногда приходят данные и вызывают иницирующую функцию (аналог main() ) соответственно экономия только на этапе инициализации и не выгружаемого из процесса кеша. Достаточно весомые преимущества в высоко нагруженных системах
а ну вот уже пошли фичи, чтож давай стабильную версию скорее и будем тестить ее повесив на *nginx на каком нибудь слабеньком VDS и посмотрим результаты
погонять тесты я уверен необходимо, но идеологически тут во первых может быть инициализация соединений с БД например, установка всех начальных значений все это помноженное на огромное количество инициализаций дает прирост. Вы сами подумайте.
1. создание объектов и агрегатов объектов (пересоздавать нада только нужные + вы можете создавать коллекции)
2. Открытие соединений к БД
3. Локальный стек статистики, который вы можете чистить регулярно а не каждый запрос.
я уверен придумать места где будет экономия можно еще — это только основные.
а вообще на основе этой штуки фактически создается событийная машина полноценная, с циклами состояний (например агрегаторы фидов рекламных где запросы очень долгие к сторонним серверам делаются влет), а на основе PHP-FPM вы этого не сделаете именно из за ежекратного перезапуска
тоесть воркерам дать возможность накапливать данные и регулярно сбрасывать свой кеш, что ж согласен так сложность системы будет существенно ниже, и соответственно выше надежность.
PS. Вы (Nascosto) для себя как я уже вижу все решили и не слушаете аргументы других людей, поэтому не вижу необходимости вас в чем либо убеждать далее. Если вам выпадет удачный случай сделать что либо действительно высоконагруженное, то вы оцените все преимущества, а так для вас это все очевидно чужое и не понятное.
работает процесс постоянно ему иногда приходят данные и вызывают иницирующую функцию (аналог main() ) соответственно экономия только на этапе инициализации и не выгружаемого из процесса кеша. Достаточно весомые преимущества в высоко нагруженных системах
1. создание объектов и агрегатов объектов (пересоздавать нада только нужные + вы можете создавать коллекции)
2. Открытие соединений к БД
3. Локальный стек статистики, который вы можете чистить регулярно а не каждый запрос.
я уверен придумать места где будет экономия можно еще — это только основные.
а вообще на основе этой штуки фактически создается событийная машина полноценная, с циклами состояний (например агрегаторы фидов рекламных где запросы очень долгие к сторонним серверам делаются влет), а на основе PHP-FPM вы этого не сделаете именно из за ежекратного перезапуска