Моделируем полёт PHP на крыльях Erlang

    В данной статье изложены размышления и фантазии на тему «как можно было бы скрестить Erlang и PHP, чтобы случилось вселенское счастье», а не описание готовой технологии или продукта. Впрочем, мы намерены это реализовать, скорее всего, в форме open-source проекта, если, конечно, уважаемая хабра-аудитория не отговорит :) Собственно, одна из главных задач этой статьи — понять, насколько идея интересна и потенциально полезна широкому PHP-сообществу. Кстати, некоторые из проблем, обсуждаемых в статье, справедливы и для других популярных скриптовых языков (тут я подразумеваю Ruby и Python), так что предлагаемое решение, возможно, будет актуально и для них.

    Предыстория

    В силу тех или иных объективных и субъективных обстоятельств в качестве языка для серверного программирования в Мегаплане используется PHP. Со временем нас начали стеснять и раздражать некоторые ограничения PHP, нам стало не хватать некоторых «продвинутых» фич, таких как: многопоточность, отложенный запуск, очереди сообщений и т.п. К тому же, мы ограничены в том, чтобы использовать под каждую проблему свои кастомные решения, поскольку Мегаплан является не только SaaS-приложением, но и поставляется в виде кроссплатформенной коробочной версии для трёх типов ОС: серверных Windows, Linux и FreeBSD. Добавление очередного кастомного компонента (даже если и нашлось кроссплатформенное решение) существенно усложняет установку и поддержку коробок. Даже отсутствие нормального стандартного crond в Windows напрягает.

    В общем, назрела необходимость «прокачать» PHP. Есть, конечно, альтернативное радикальное решение — переехать на Java, но для нас это не вариант — слишком много не самого плохого кода уже написано за несколько лет. К тому же я не уверен, что на JVM можно элегантно решить проблему масштабного comet'а. Да и PHP списывать рано — он всё ещё является самым популярным языком для веб-разработки (по крайней мере, в России), программистов найти проще, чем под другие языки.

    На почве созревшей необходимости и того, что мне в определённый момент попался на глаза и очень понравился Erlang, созрела идея решения проблем — встроить в наше стандартное окружение виртуальную машину Erlang'а и компенсировать недостатки PHP уникальными возможностями этого функционального языка.

    Сначала расскажу о том, какие задачи при помощи «чистого» PHP делаются с трудом и каких фич нам не хватает, а затем опишу предполагаемое решение. Итак…

    Проблемы

    В данной статье я исхожу из того, что долгоиграющие процессы в PHP — это исключительно ненадёжный костыль, под который нужно подставить ещё один костыль, чтобы оно как-то жило. Не вселяет оптимизма даже то, что в PHP 5.3 вроде появился нормальный сборщик мусора. Не убеждает и phpDaemon, который многим нравится, но завязан на libevent, поэтому под Windows работать не будет. На текущий момент не существует нормального нативного и, главное, надёжного способа «демонизации» программ на PHP. И даже если пытаться переходить на тру FastCGI, всё равно над этим хозяйством нужен диспетчер, который будет регулярно процесс перезапускать. Короче, на мой взгляд, единственным продакшн-режимом работы PHP является классический FastCGI (или apache+prefork+mod_php под unix-like системами).

    Почти все ограничения, о которых пойдёт речь, связаны с этим обстоятельством.

    Фоновый запуск


    Думаю, многие разработчики, которые писали на PHP чуть больше, чем «Hello World!», сталкивались с проблемой отложенного запуска, например, при элементарнейшей задаче отправки электропочты в ответ на какое-либо действие пользователя. В PHP есть 2 решения для такой задачи (оба некрасивые):
    • либо пытаться отправить письмо прямо сразу в интерактивном режиме в том же скрипте и рисковать нарваться на тормознутость и недоступность почтового сервиса,
    • либо записать где-нибудь задание на отправку и раз в минуту дёргать по cron'у скрипт, который эти задания будет разгребать.
    Знакомо? Вы, наверное, возразите, что есть и другие способы, например, такое извращение: отфоркать новый процесс с помощью pcntl. Но тут я отвечу, что это как минимум не кроссплатформенно, и вообще выглядит как хак. А хочется иметь красивое и надёжное решение.

    Comet


    Все новомодные вкусные вещи типа long-polling, websockets и т.п., конечно, можно сделать и на чистом PHP, но вот только ценой целого долговисящего php-процесса на каждое соединение. На сколько-нибудь серьёзном количестве клиентов ресурсов не напасёшься на такую роскошь.
    Я слышу, как в дальних рядах кто-то заикнулся про многопоточный (worker) mod_php с apache на пару. Ребята, не используйте thread-safe php в продакшне, это неправильно. Тем более, что на действительно серьёзных нагрузках даже это не спасёт.
    А нам очень хочется иметь общее пространство событий между клиентом и сервером. Ну вот представьте себе такую сказку: сервер инициирует событие:

    <?php
        Event::publish( 'common.users.onlinecountchanged', array('count' => 10) );
    ?>
    

    А в браузере можно на него подписаться и среагировать практически сразу и не дёргая запросами сервер каждую секунду:

    Event.subscribe( 'common.users.onlinecountchanged', function(data) {
        $('#onlinecount').html(data.count);
    } );
    

    Для того, чтобы организовать адекватный web-jabber-чатик, тоже нужна эта технология.

    Мощный кроссплатформенный cron


    Cron-заданиями пользуются почти все PHP-приложения, но в классическом cron'е есть два недостатка:
    • Нет универсального кроссплатформенного решения.
    • Неудобно динамически управлять заданиями из PHP-приложения и, соответственно, создавать одноразовые задания на какой-то момент в будущем.
    В Мегаплане для реализации механизма напоминаний необходимо запускать некоторые действия единоразово в определённый момент в будущем. Для этого используется внутренняя система планирования заданий, однако для того, чтобы вовремя инициировать запуск задания, приходится применять различные костыли вроде «запускать каждую минуту по cron'у и проверять — не нужно ли чего-то сделать в данный момент», а когда на одном сервере работают тысячи аккаунтов и у каждого свой список заданий, приходится придумывать специальные дополнительные костыли, чтобы не дёргать понапрасну каждую минуту тысячи PHP-скриптов.

    Было бы здорово иметь надёжный кросплатформенный планировщик заданий,
    • которым можно было бы динамически управлять из PHP-приложения,
    • который без проблем поддерживал бы тысячи заданий,
    • который дёргал бы PHP только тогда, когда действительно нужно запустить задачу,
    • который заменил бы cron, чтобы не думать об операционной системе, на которой работает наше PHP-приложение.

    Очереди сообщений (message queue)


    Очереди сообщений — мощный инструмент для целого класса задач. В частности, фоновые задания или событийную модель, о которых говорилось выше, логично реализовать через очереди сообщений. Думаю, никто бы не отказался иметь готовую инфраструктуру для организации асинхронных очередей «из коробки» без лишней головной боли.

    Подробнее о пользе очередей сообщений можно почитать, например, в этой подборке презентаций на тему.

    Решение

    Как я уже говорил, принципиальное решение всех этих задач я вижу в добавлении к PHP элемента надёжности и долговечности, которыми он не обладает, в виде виртуальной машины Erlang.

    Почему Erlang?
    • Erlang создан для того, чтобы работать без перерывов долгое время. На нём работают крутые телефонные коммутаторы. Даже обновление кода можно делать без остановки работы.
    • Он кроссплатформенен и открыт с нормальной не GPL-подобной лицензией, позволяющей распространять его с коммерческими приложениями.
    • Концепция легковесных процессов позволяет создавать параллельно многие тысячи висящих соединений без особого ущерба для производительности — это позволяет эффективно решать проблему Comet'а.
    • На Erlang'е написан один из самых известных и мощных серверов очередей сообщений с поддержкой AMQP — RabbitMQ.
    • И вообще, этот язык хорошо подходит для задач диспетчеризации, надзора и всякой асинхронной кухни.
    Кстати, в заключительной части статьи про то, как подружить популярные PHP-фреймворки и CMS с YAWS (YAWS — это веб-сервер, написанный на Erlang'е) у автора точно такие же мысли про симбиоз PHP и Erlang'а, это греет мне душу — я не один такой, нас, как минимум, двое! :)

    Схема


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

    Некоторые комментарии:
    • Nginx я нарисовал только для того, чтобы отбиться сразу от фраз типа «Nginx — наше всё, как же нам без него жить?!». Да, конечно же, это наше всё, если нужно, можно его поставить до Erlang'а и обрабатывать им то, что нужно. Но и без него всё будет работать.
    • Mochiweb я нарисовал как один из вариантов. Какой именно из веб-серверов, написанных на Erlang'е, использовать — это ещё вопрос дополнительного анализа.
    • Я нарисовал только менеджер FastCGI, однако вполне можно написать и менеджер долговисящих PHP-процессов, которые, например, «слушают» свои очереди по AMQP и спокойно их обрабатывают (например, те же письма шлют), а задача менеджера — регулярно их перезапускать и следить, чтобы их было нужное количество.
    Далее немного о компонентах и о том, как на всём этом можно решать обозначенные задачи.

    Сервер очередей сообщений — RabbitMQ


    Сервер очередей — один из основных компонентов, ради которого всё и задумывалось. Это «транспортное средство» для различных очередей заданий и для организации единого пространста событий между компонентами, которые могут быть написаны на разных языках и работать на удалённых серверах.

    Всю эту мощь обеспечивает поддержка протокола AMQP. На хабре можно найти целый ряд статей по теме, поэтому не буду заниматься пересказом. Наиболее удачные вводные статьи, на мой взгляд: раз и два. Про то же, но в контексте PHP: раз, два и три.

    Универсальная шина событий (pub-sub)


    При помощи RabbitMQ довольно просто построить гетерогенную pub-sub систему. Давайте представим, что в приложении на PHP возникают события, на которые могут подписываться и реагировать какие-либо внешние сервисы. Тогда на стороне PHP при возникновении события мы написали бы примерно такой код (здесь используется библиотека PECL AMQP):

    <?php
    // соединяемся с RabbitMQ
        $cnn = new AMQPConnection();
        $cnn->connect();
    // Объявляем обменник, который поддерживает подписку по маске
        $ex = new AMQPExchange( $cnn );
        $ex->declare( 'event-exchange', AMQP_EX_TYPE_TOPIC );
    // публикуем событие
        $ex->publish( 'message', 'some.object.event' );
    ?>
    

    Дальше представим, что мы при помощи какого-либо интерфейса зарегистрировали в Erlang'е, что при возникновении события some.object.event нужно вызвать некий внешний REST: http://example.com/example-action. Тогда процесс в Erlang, который слушает и реагирует на событие, имел бы примерно такой код (пишу с сохранением логики на псевдо-PHP, чтобы было понятнее):

    // объявляем обменник и очередь
        amqp_declare_exchange( 'event-exchange', AMQP_EX_TYPE_TOPIC );
        amqp_declare_queue( 'external-app-queue' );
    // подписываем очередь на все сообщения с обменника по маске
        amqp_bind( 'external-app-queue', 'event-exchange', 'some.object.*' );
    // подписываем текущий процесс на очередь
        amqp_subscribe( 'external-app-queue' );
    // слушаем, когда из очереди пойдут сообщения о событии
        while ( 1 )
        {
            $msg = receive_message();
            file_get_contents( "http://example.com/example-action?msg=$msg" );
        }
    

    Таким образом, когда PHP-приложение публикует сообщение в обменник event-exchange с ключом some.object.event, обменник видит, что очередь external-app-queue подключена к нему с маской, которой соответствует ключ some.object.event, и отправляет сообщение в эту очередь. Далее очередь, зная, что на неё подписан Erlang-процесс, отправляет сообщение в него, а процесс уже выполняет логику по вызову callback'а для этого события (в данном случае — обыкновенный REST-запрос по HTTP).
    Если вы осилили прочтение предыдущего абзаца, возьмите с полки пирожок :)

    Менеджер FastCGI


    Зачем может понадобиться писать FastCGI-менеджер на Erlang'е? Всё из-за той же кроссплатформенности. Я был бы счастлив, если бы php-fpm поддерживал Windows, но, к сожалению, это не так и, видимо, никогда не будет. В конечном итоге хочется получить полноценный стек для запуска веб-приложений на PHP, наподобие LAMP.

    Это, пожалуй, самое сложное из того, что предстоит сделать.

    Веб-сервер и Comet


    Веб-сервер на Erlang'е нужен по одной простой причине — можно легко позволить себе держать по одному процессу на долгоживущее (long-polling) соединение и не думать о ресурсах — накладные расходы на создание и работу легковесных процессов Erlang'а очень небольшие. Если вы вдруг не знаете, что такое comet и как его можно организовать между браузером и веб-сервером, отправляю вас в соответствующую обзорную статью.

    Comet в предлагаемой схеме работает при помощи универсальной шины событий, описанной чуть выше, только в роли Erlang-процесса-обработчика событий выступает процесс веб-сервера, обслуживающий long-polling соединение с клиентом, и вместо http-запроса он просто отправляет все полученные сообщения по push-каналу в браузер. Полный алгоритм примерно такой:
    1. Javascript-код в браузере открывает долгое соединение, одновременно подписываясь на определённые события.
    2. Erlang-процесс, обслуживающий это соединение создаёт на RabbitMQ свою очередь, подписывает её на нужные события на обменнике и сам подписывается на получение всех сообщений из очереди. Здесь нужно ещё не забыть про механизм авторизации, чтобы клиент смог подписаться только на те события, к которым у него есть доступ.
    3. PHP-приложение публикует событие на обменнике RabbitMQ, оно раскидывается по всем очередям comet-клиентов, которые подписаны на это событие.
    4. Сообщение попадает в обслуживающий процесс каждого клиента, который подписан на событие. Сообщение передаётся в браузер по push-каналу.
    5. В браузере срабатывает callback push-канала и в зависимости от события происходит соответствующая реакция.
    6. Push-канал тут же открывается заново (если это long-polling).

    Менеджер заданий


    Если вы уже поняли основную идею, то, наверное, вам уже очевидно, что организовать выполнение фоновых заданий в предложенной схеме проще простого: достаточно создать отдельный обменник для заданий, одну или несколько очередей для самих фоновых задач и соответствующие обработчики этих очередей. Обработчики можно придумать двух типов:
    • Элементарный вызов по HTTP-REST API. В этом случае параметры запроса нужно присылать в самом сообщении.
    • Долгоживущий PHP-процесс (запускаемый и надзираемый из Erlang'а), который «слушает» свою очередь заданий по AMQP и выполняет одну специфическую задачу.

    Cron


    Отложенный на момент времени в будущем запуск также несложно организовать в виртуальной машине Erlang. В ней есть встроенные средства для эффективного хранения данных как в памяти, так и на диске. Достаточно сохранить время, в которое нужно совершить действие, и соответствующее сообщение с информацией о задании для менеджера заданий. Написать на Erlang'е процесс, который будет, имея эту информацию, вовремя отправлять задание в очередь менеджера заданий (см. выше), не составляет большого труда. А чтобы запланировать задание, можно либо отправить сообщение в нужный обменник AMQP, либо сделать REST API и управлять заданиями через него.

    Что касается периодических заданий, как в настоящем cron'е, можно, конечно, и их реализовать (а может, это уже кто-то сделал в просторах Интернета), но это не столь критичная задача, поскольку её вполне можно и на PHP сделать (собственно, в Мегаплане такой механизм есть), главное, чтобы был надёжный инициатор, который вовремя вызовет PHP-скрипт.

    Вместо заключения

    Дочитавшим до этого места большой респект и спасибо, надеюсь было не очень скучно :)
    Итак, что мы получим, если описанный проект вдруг реализуется:
    • Кроссплатформенную и при этом надёжную среду для запуска веб-приложений на PHP.
    • Кучу дополнительных продвинутых возможностей для PHP с разнообразной асинхронной магией.
    • Более быстрые и отзывчивые веб-приложения с real-time оповещениями.
    • Популяризацию замечательного Erlang'а.
    В общем, один сплошной профит :)

    Хотите поучаствовать? Welcome!
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 166

      +5
      Очень толковое предположение. Особенно вам понравится тот факт, что в одной VM можно запустить кучу всего и оно не будет друг другу мешать.

      Единственное что я не уверен, что вам сходу подойдет RabbitMQ. Этот прекрасный продукт заточен под быструю доставку чудовищного количества сообщений, а вам бы иметь возможность послать сообщение с таймаутом.

      Возможно обойдетесь малой кровью в виде небольшого фронт-прокси перед RabbitMQ.

      github.com/noss/ifastcgi Это видели? Нерабочее?
        0
        > а вам бы иметь возможность послать сообщение с таймаутом.
        для этого можно отдельный сервер написать, я об этом написал в разделе про cron

        ifastcgi видел, но, насколько я понял, это только реализация протокола, но оно не умеет запускать и управлять процессами обработчиков.
        +5
        Замечательная статья.

        Симбиоз стейтлесс-языка для комет, очередей, шаблонизации и кэширования/маршрутизации и php в качестве дешёвого для разработки бизнес-логики бэкенда давно напрашивается.

        Если вы будете открывать проект под совместимой с работой сообщества лицензией — то отписывайте прогресс, будет интересно.
          +8
          Что-то мне показалось, что некоторые пункты притянуты за уши.

          Отправка писем — в линуксе, на сколько я знаю, письма мгновенно встают в системную очередь, а дальше почтовый демон думает об отправке, о повторной отправке и прочем хламе. Если под виндой нет такого демона, то именно его и стоит завести.

          Реализовывать крон на эрланге — микроскоп и гвозди. Напишите свой крон на пыхе универсальный и кросплатформенный. Я так и не понял, чем вам пых запущенный надолго не угодил.

          Очереди — так вы сами и ответили. Есть разные решения для организации очередей сообщений.

          Зачем без особой на то нужды нанимать программиста на довольно экзотическом языке программирования? Другое дело, если б вы уже использовали где-то Erlang.

            0
            письма мгновенно встают в системную очередь

            И на smtp-сервер мгновенно отправляются?
              +3
              Вручную соединяться с smtp сервером? Нафига? Для этого много лет назад придуман sendmail.
              +1
              Если вместо миллиарда костылей и риторики можно сделать красивое решение — почему бы нет?
                +1
                Я где-то предложил костыли?
                Наоборот я как раз думаю, чтобы нарисованная связка заработала как раз и потребуется миллиард костылей.
                  0
                  Думаю, я некорректно сформулировал мысль. В статье автора приведён список костылей для решения определённых задач, и, как итог — решение (вдруг изкоробочное и монолитное?), которое может от этих костылей избавить. Разве это плохо?
                    +6
                    Плохо, что нет обоснования нафига всё это надо объединять в монолит или коробку. В монолит имеет смысл объединять систему решающую определённый класс задач.

                    Какие же задачи будет решать эта система? Лонг поллинг и отложенное выполнение для PHP?
                    Для этого предлагается объединить 3 монстров (сервер очередей, вебсервер и крон) и после этого ожидать, что это будет надёжная среда.

                    Наоборот, мне кажется, это будет комшар разработчика при отлавливании багов.
                      0
                      Обоснование простое — нужно сделать коробочную систему планирования. К сожалению, изначально был выбран не очень подходящая для реализации систем непрерывного действия инфраструктура (насколько я понимаю — целиком на PHP и сопряжённых технологиях) со множеством подставок. Как водится, теперь проще построить новый инфраструктурный фундамент из Erlang (при должной сноровке разработчиков багов там практически не будет), который заменит собой дуэт японских плохишей-годзилл (а, в перспективе — и вебсервер) и уже потом, используя почти непотопляемый (а в случае с Erlang это так и есть) остов, перестроить пхп-бэкенды. Либо на том же пхп, либо на Erlang ( вдруг понравится?). Я даже не хочу говорить о нагрузках, которые будет способен пережевать такой фундамент ( особенно с энджайниксом в качестве фронта).

                      Вроде нормальное обоснование. На словах, по крайней мере, не знаю уж как там с экономической составляющей.

                      А кошмара для разработчиков при условии нормального проектирования API к этому монолиту просто не видно.
                        –2
                        Про должную сноровку разработчиков. Я бы как раз не стал выбирать эрланг именно по этой причине. Питон и Ява более понятны пхп-разработчикам и специалистов на них гораздо больше. Проект на Эрланге может встать на пол года из-за ухода / болезни и т.п. 1-2 вменяемых разработчиков, которым замену просто так не найти.

                        Про непотопляемость. Вот этого я никак понять не могу. Какая нагрузка будет у коробочного решения? Компания из 1000 пользователей? 1-2 клика в секунду в пике нагрузки? На это хватит любого, даже коряво настроенного, сервера. Тут нагрузка играет крайне малую роль. А размах такой, что с аналогичными трудозатратами можно писать демонят на чём угодно. На Сях, Питоне, Яве, вкомпилированными модулями для Пхп и т.д. и т.п.
                          +1
                          Это какое-то очень странное выссказывание: «ява понятна пхп разработчикам». Я проверял: переучить на erlang — неделю, две. На яву в месяц не уложишься.
                            +1
                            Перефразирую. Код на Яве читать проще, ООП роднее и понятнее. На Эрланге надо думать по-другому. За 2 недели можно выучить синтаксис, но не вывихнуть себе мозг.
                              0
                              Если пользовались лямбдами, дженериками и прочей вкусностью типа линка в джавах и сишарпах — ничего сложного.
                                +1
                                Чушь, бред, фигня. Код на джаве может быть в 10 раз длиннее аналогичного кода на erlang. 10-кратное размазывание логики по дурному синтаксису очень плохо сказывается на читаемости кода.
                                  0
                                  Ага. А код на Эрланге может быть в 10 раз длиннее кода на Яве. Писать на Перл можно на любом языке…
                                    +1
                                    SomeBigClassNameAsUsualInJava someBigVariableNameAsUsualInJava = new SomeBigClassNameAsUsualInJava();

                                    уж что-что, а verbosity у джавы зашкаливает.
                                0
                                Да — что на яву, что на шорпиё, что на любой другой язык человек, в общих чертах знакомый с целевой парадигмой и приличным опытом переходит за две-три недели, а уверенно использовать может через месяц-три. Это, конечно, если есть фуллтайм-занятость и мотивация. ПМСМ.
                                  +1
                                  На яву за месяц уложишься, НО джава это в первую очередь её архитектура (читать как куча специфических библиотек), а учить её долго. Хотя, ценителям Zend_Framework должно понравится.
                                  Увы, но даже знания синтаксиса erlang не обеспечивают мгновенное понимание OTP. В первое время разработчики будут писать «php-код» на erlang.
                                    +1
                                    Мне кажется, что в первое время разработчики будут писать «php-код» что на Яве, что на шарпах… Я много раз видел подобные примеры. Кстати, видел и обратный пример — когда Ява-разработчик писал на PHP… разбираться в этом было очень непросто. Всё таки у разных языков разный подход.
                                      0
                                      Проблема в том, что при «общении» с языком формируются пути решения проблем. Для java — это, упрощенно, «найти и прикрутить» готовый модуль, причем прикрутить его, порой, сложнее, чем написать :) Поэтому ценится разработчик, умеющий работать с определёнными библиотеками (например, gui java разработчик вряд ли напишет что-то под web если этим не занимался раньше). То есть, тот факт, что java-разработчиков много, не означает того, что сразу найдешь нужного специалиста (а специалисты обычно уже окучены и работа у них есть).
                                      Для php — это обычно написать что-то, а потом узнать, что это решение делает 100+ запросов к базе и надо переписывать нормально. А строгого архитектурной платформы до поры до времени не было, поэтому разработчики успели написать столько своих разных велосипедов, что можно говорить, что «php php рознь». Попробуйте дать код drupal адепту Zend Framework.
                                      Разработка на erlang, в принципе, однопрофильная и разработчику надо знать меньше абстракций, чем в той же java. А вот прикручивать в плане модулей часто будет нечего.
                                        +1
                                        Для php — это обычно написать что-то, а потом узнать, что это решение делает 100+ запросов к базе и надо переписывать нормально.

                                        А что плохого в подходе «преждевременная оптимизация — зло»? :)

                                        Другое дело, что для PHP обычно, увы, сначала написать что-то своё, потом дописать к нему кучу костылей, потом понять узнать, что есть библиотека или фреймворк, реализующее тоже самое, но лучше и красивее, а потом сидеть и выбирать, что лучше — переписать свою инфраструктуру без костылей, практически не трогая логику (если повезло); адаптировать логику под стороннюю инфраструктуру или писать очередной костыль, потому что заказчик кричит, что фича, от которой он отказался год назад, ему была нужна ещё вчера.

                                        Да и сейчас, вроде, строгого архитектурного стандарта де-факто (читай — доминирующего фреймворка) для PHP как-то не наблюдается. Одни тянут совместимость чуть ли не с PHP3, другие на неё забивают и ориентированы на вчерашний релиз. Одни не используют магию, другие используют, причём каждый свою. Одни, складывается впечатление, видят своим идеалом ту часть мир Java, что с километровыми XML-конфигами, другие — RubyOnRails, которые сами знают, что нужно разработчику, а если ошибаются, то не рельсы, а разработчик, думая что ему нужно то, чего в гемах нет :)

                                  0
                                  Я боюсь оказаться голословным и самонадеянным, но, смею полагать, что то, что будет написано на эрланге — оно не потребует фуллтайм-программиста на поддержку. Также я думаю, что разработчики мегаплана подумали об этом и сознательно пошли по этой дорожке.

                                  Непотопляемость — это дополнительное свойство. Я так понимаю, что планируется на базе одной «платформы» построить локальные системы, саас и общедоступный сервис. Вполне возможно, что в последних двух случаях отказоустойчивость будет очень к месту.
                                    0
                                    вот здесь написано про окамл, как боялись писать проект на окамле по тем причинам, которые вы называете, и как написали, и как все эти риски оказались надуманными.
                                    (да, окамл, конечно, не эрланг, но тоже эзотерический язык с точки зрения среднего пхп-программиста)

                                    что касается явы/питона, то вы представляете себе затраты времени и людей на переписывания проекта на эти языки?
                                      –3
                                      Не переписывания. Нам что нужно? Крон и очереди? Пишем демона на Сях, Яве, Питоне и т.д. Пишем модуль для Пхп или Апатча или чего угодно ещё. Как по мне так по трудозатратам примерно один хрен получится. Вопрос — почему Эрланг? Просто потому что «он клёвый»? Эрланго*** детектед?
                                        0
                                        я сомневаюсь, что «пишем демона, отлаживаем демона, деплоим демона, пишем модуль, отлаживаем модуль, деплоим модуль» будет проще.
                                      +2
                                      Так речь не идёт о том, чтобы разработчики, которые пишут прикладной софт на PHP изучали для решения описанных задач Erlang. Речь о том, чтобы сделать документированный продукт, с помощью которого PHP-разработчики будут решать задачи, используя только PHP и соответствующее API.
                                        0
                                        По опыту с 99% вероятностью рано или поздно придётся влезать в код соседнего продукта. Причины могут быть разные. Чаще всего чтобы посмотреть как что-то устроено.
                                          +1
                                          Среднестатистический похапэ-разработчик часто залезает в код MySQL, Apache или, не дай бог, самого PHP?
                                            0
                                            Соседнего — который разрабатывают в той же конторе, где он сам работает.
                                              0
                                              Чем в НОРМАЛЬНОЙ конторе (даже гетерогенный по средствам реализации) софт отличается от приведённых мной примеров?

                                              Я понимаю, что иногда можно залезть внутрь исходников, поглядеть, почитать, посамообразовываться. Но если это нормальный софт с документацией, пройденным QA, актом ввода в коробочную эксплуатацию — то на правку туда лезть никому не дадут, а, следовательно, минусов никаких быть не может.

                                              Разве что несколько самых вменяемых пхп-кодеров мутируют в нормальных программистов и уйдут из проекта на эрланг-поля с зарплатой в два-три раза повыше. Но это же хорошо для индустрии, нет? ;D
                                                0
                                                Ага-ага. Софт с документацией, пройденным QA, актом ввода в коробочную эксплуатацию… Вы такое часто видели? В идеальном мире конечно так и бывает, но в реальности как всегда «по самым разным причинам», всё происходит иначе. Как говориться, пусть кинет в меня камень тот, кому ни разу в жизни не приходилось выкатывать «сыроватый» продукт. Ну и далее, недотестированность, косяки и, самое страшное, устаревание документации и т.д. и т.п. Это же рапид-девелопмент, привет! ) Быстро и с идеальным качеством никто ничего никогда не выпустит.
                                                  0
                                                  Видели. Россия не везде страна безответственных жизнерадостных алкашей и идиотов. Просто не надо документацию делать бездумно для галочки, QA отпускать на самотёк (экономя на этом денежку на новый кожаный диван для жаханья секретарш), а акты подписывать за бутылкой армянского коньяка.

                                                  Это аргументы из серии «ну а может вот так?». Не надо этого, пожалуйста. Как правило, всё очень хорошо, если на это хорошо не смотреть через чёрные очки.
                                                    –3
                                                    Так чего вы сидите. Бегите подавать заявку в книгу рекордов Гиннеса. Вы — уникум. Ну или у вас мало опыта, но по возрасту не скажешь. Или ещё вариант — контора из 3-х человек. Или работа на забугорье (и то там тоже очень разное бывает). Всё. Других объяснений я придумать не могу.
                                                      +1
                                                      Давайте не будем опускаться до уровня низших приматов.

                                                      Я не уникум, просто надо любить свою работу (иногда даже через «не хочу»), пускать в неё хороших людей и устраивать её так, чтоб этим людям было комфортно. А это тоже работа. Которую у нас в стране делать не любят.
                                                        0
                                                        В конечном итоге искренне рад за вас, если у вас правда всё бело и пушисто. Но гложет то, что своими глазами я идеального мира не видел и от друзей о таком не слышал, хотя и сам работал в не последних компаниях рунета, а уж некоторые из друзей вообще в компаниях мирового уровня.

                                                        Другое дело что иногда тест-драйв-девелопментом или проходом QA называют наличие в 4 тестов, которые написал «самый умный». Документацией называют прогон конвертилки из камментов к коду в красивый html для соответствующего языка. Ну и т.д. и т.п.

                                                        Любить работу — это правильно и хорошо. Но обычно практичность бьет чистоту. Иногда слишком сильно…
                                      –1
                                      Если задача — сделать мощную инфраструктуру с вбесервером и очередями, то почему бы не взять что-то готовое на Java? Я считаю использование Erlang для данной задаи экономически неоправданным.
                                        +1
                                        Они и берут готовое, только на Erlang, вебсервер и очереди уже реализованы, достаточно лишь связать их в единое целое.

                                        Вам больше Java нравится? Хорошо, вот и делайте на ней что хотите, только не надо другим капать на мозги, что это самое лучшее решение. Не факт, что по времени и деньгам на Java выйдет лучше, скорее наоборот.
                                          +2
                                          Что специфично. Точку зрения, что это надо делать на Эрланге, отстаивают именно эрлангеры. Нет поклонение своей плфтформе — дело хорошее.

                                          Но вот экономическая целесообразность использование эрланга для данной задачи — совсем неоправдана. Начиная от подбора персонала, заканчивая долгосрочной персективой поддержки.

                                          Я сейчас рассуждаю сейчас не как воодушевлённый фанатик, а как практик. Чего не скажешь о вас. Где вы видите, что я «капаю на мозги, что это лучшее решение»? Я задал вопрос про альтернативное решение.

                                          Для себя бы я наверняка выбрал Erlang, ибо пишу на нём уже несколько лет. Но вот для фирмы Мегаплан как таковой, я не вижу смысла вкладываться в Эрланг, если у них нет своих Эрланг разработчиков.
                              +2
                              Вы, видимо, ничего не поняли.
                              Как они могут написать «свой на пыхе», если есть четко описанные проблемы с демонизацией. Есть проблемы с администрированием всего этого.

                              Когда выкатываешь коробку клиенту надо, что бы была только одна движущаяся деталь: один демон запустил/остановил.
                                –1
                                Нужно, как правило, два скрипта — для запуска и остановки всего этого безобразия. А что там запустится и в каком количестве — это уже не важно.
                                Если пых не подходит для демонизации, так выберите другой язык подходящий для демонизации.
                                  +1
                                  Они и подобрали. Это erlang
                                0
                                Отправка писем — это всего лишь один из возможных вариантов фоновых задач. Ну и вы сами сказали, что в windows красивой локальной очереди писем нет.

                                Я пытаюсь найти правильный инструмент для решения задачи. Пых — плохой инструмент для реализации демонов, для меня это очевидно и холиварить на эту тему я не буду.

                                Erlang — хороший инструмент для организации надёжных систем, к тому же очень интересный, несмотря на то что немного экзотичный. А ещё он один подходит для решения всех описанных задач.
                                +1
                                Гм… интересное решение, кстати, спасибо на ссылки на мои статьи :) приятно.

                                По существу — я раньше тоже рассматривал AMQP, но потом попробовал, что связка Node.JS + PHP + Redis решает все эти задачи, не требует экзотического языка, а редис в качестве решения для подписок, реалтайма и хранения части данных показал себя идеально. Комет реализуется на базе Node.JS, кластеризируеться через Redis.
                                  +2
                                  Вы связываете аж два экзотических решения (Node.js, Redis) с третьим, используя четвертое, пятое и шестое для запуска PHP.

                                  Люди же хотят оставить вместо целой пачки всякого софта только один надежно работающий кусок: это сервер на erlang, который будет сам запускать всё что надо и следить.
                                    0
                                    они никак не экзотические. По крайней мере не более, чем ерланг. Уж JS то знают все :) А то, что например, ерланг даже не ставиться в дебиане на нескольких серверах, и понять что и почему никак нельзя, а тех кто может понять — их раз два и обчелся на весь город…
                                      +4
                                      Почему вы говорите о том, чего не знаете? В squeeze по умолчанию достаточно свежий эрланг, в sid вообще валяется самый свежий. Отсутствие зависимостей делает бекпорт тривиальным. Плюс к тому эрланг без проблем упаковывается в standalone бинарь с зависимостями в виде единственного libc, что вообще нивелирует проблему развёртывания на продакшне. Да, признаю — сейчас нет (ну или я не знаю) готового решения, обеспечивающего выкатывание горячих апгрейдов поверх такого стендалон-бинаря, его нужно написать самому (порядка нескольких десятков строк кода, я полагаю, и хорошее понимание принципов работы OTP). Но это возможно, в отличие от остальных упомянутых вами языков.
                                      Далее. Аргумент «JS знают все» — не аргумент хотя бы потому, что так же все знают, что JS — порождение ада. Писать сервер на чём-то, что не умеет всё это и нахваливать может только похапешник, привыкший к таким прелестным вещам, как текстовые инклюды без неймспейсов или пляски с бубном вокруг демонизации.
                                      И наконец аболютно все, кто изучал эрланг, в один голос утверждают, что он не прост, а очень прост в изучении. За 2-3 недели можно спокойно подтянуть до такого уровня, чтобы садиться и писать код в готовом проекте. Полтора-два месяца — и можно начинать свой проект (потому как OTP сложнее, чем сам erlang, но если в команде есть хотя бы один опытный человек, проблем не будет).
                                        0
                                        да именно так — все это не особо нужно. нужен гибкий и красивый язык, а не треды и прочее, тчо вы там написали в комментарии. А то так можно сразу заявить, что языки без статик типизации вообще не нужны :)

                                        если так просто — почему ерланговцев так мало?

                                        P.S. Извините, но я знаю о чем говорю — когда пишу, что я ставил и даже отр среда не установилась из коробки на свежем дебиане ленни на ес2 инстансе.
                                          +4
                                          >свежем дебиане ленни
                                          >свежем
                                          >ленни
                                          Извините, у меня не парсится.
                                          >нужен гибкий и красивый язык, а не треды и прочее
                                          Прошу прощения, а «треды и прочее» — не свойства языка, что ли? Или вы про синтаксис? Ну так синтаксис эрланга приятнее лично мне, чем питоновский, например.
                                          >языки без статик типизации вообще не нужны
                                          На самом деле не нужны. Просто пока что многовато нужно знать для того, чтобы писать нормально на языках с нормальными системами типов, хотя код и может выглядеть очень красиво, пруф.
                                          При этом абсолютно точно не нужны языки со слабыми системами типов (см. JS, см. PHP). В эрланге как раз сильная типизация и опциональный тайпчекер (см. Dialyzer), всё более становящийся обязательным (ну или правилом хорошего тона).
                                          >если так просто — почему ерланговцев так мало?
                                          Если всё так просто — почему программистов так мало по сравнению с менеджерами? Программисты не нужны, разогнать всех и работать менеджерами.
                                  +1
                                  Многопоточность и очереди сообщений прекрасно решает gearman. Отложенный запуск вроде в последних версиях прикручивали, сам не пробовал.
                                  Опять же клиенты и воркеры могут быть на разных языках, у нас вот Java и PHP. Под виндой gearman запустить можно, ибо есть перловая версия. Думаю C-шную тоже не так долго поправить.
                                    0
                                    С-шный на libevent'е вроде, вряд ли его легко переделать.

                                    А к перлу у меня личная неприязнь, сори :)
                                      0
                                      Ну если вы не любите ни perl ни C, есть еще Java вариант сервера :).
                                      Правда как я понимаю у вас нет цели найти простое решение, есть цель обсудить решение с erlang
                                        0
                                        В принципе, java — единственный альтернативный кроссплатформенный вариант решения всех обозначенных задач.

                                        Но java — это универсальный монстр, на котором вроде как даже операционную систему написали уже. А erlang — инструмент, который хорошо решает именно те задачи, которые нужно, и есть подозрение, что эти задачи он решает лучше, чем java.

                                        Кроме того, вам не кажется каким-то странным сочетание java и php? Сразу напрашивается вопрос — если уже java стоит, на фига php? На java можно решать все задачи, которые решаются на php. А вот на erlang писать веб-приложения, конечно, можно, но это не самый прямой путь.

                                        Вот и получается, что по охвату функциональности: erlang + php = java :))
                                          +2
                                          Erlang очень хорош для своего круга задач, тут я не спорю, приходилось сталкивать немножко. Просто он в наших краях все-таки экзотика и найти хорошего специалиста написать и поддерживать сервис реализующий все что вам надо и поддерживать мне кажется будет не самой простой задачей.
                                          C Java таким проблем нет. А то что Java универсальный монстр меня не смущает ни капли. Использовать Erlang только потому что на нем НЕудобно писать то что должен делать PHP по-моему странная мотивация.
                                          Соответственно проект переписывать на Java я бы не стал. Инфраструктурные вещи — Java, бизнес-логика PHP. Опять же Java Bridge есть, так что если надо можно напрямую вызывать Java без прочих замороков прямо из PHP, не говоря уж о том же gearman.
                                            0
                                            Спасибо за конструктивный ответ. Я «помедитирую» над вашим предложением :)
                                              +2
                                              C Java таким проблем нет.

                                              Ну вот опять. Почему вы думаете, что раз проект написан на java, значит любой java программист сможет его сопровождать?

                                              Если человек до этого писал только бизнес логику с SQL-ем и всякие GUI, а вы его посадите на сопровождение чего-то масштабируемого, многопроцессорного или асинхронного, то его опыт никак ему не поможет. Пусть там хоть «java — 10 лет», он вам так накосячит, оставит скрытые race conditions, которые вы будете потом 5 лет вылавливать. Тут нужен совсем другой опыт, а не знание синтаксиса языка.

                                              Вы отправите объявление о вакансии, и к вам повалят java программисты, потом вы будете гадать, много он вам накосячит или нет? Он будет работать с ядром, критической частью. Опасно. Десятки собеседований, десятки отказов. Семь потом сойдёт.

                                              А вот с эрлангом таких проблем нет. На нём ничего другого не пишут. 1 год эрланга === 1 год concurrency и масштабируемых систем. Даже во время обучения, ставятся мозги так, чтобы человек по минимуму косячил.

                                              На объявление откликнутся 3-4 человека. Нужный навык будет у всех.
                                                0
                                                Я не говорю что прям любой, но как минимум выбор будет. Когда нам надо было поковыряться с Erlang на прошлой работе пришлось осваивать самим. Сугубо с этой точки зрения, впрочем у нас провинция, может в Москве ерлангистов хоть жопой жуй.
                                                Еще тут также как в случае Erlang все компоненты кроме разве что менеджера FastCGI уже более-менее готовы, надо лишь собрать в кучу. Так что опыт в написании инфраструктуры конечно нужен, но супермен который будет писать все с нуля годами нет.
                                              +1
                                              Все разглагольствования на тему явы закончатся после запуска приложения на erlang, которое влезет в 40 метров памяти и на яве, которой не хватит 1 гб
                                                0
                                                Сразу напрашивается вопрос — если уже java стоит, на фига php?
                                                Написали же: есть код уже в эксплуатации на php и это основной язык в организации, а переписывать и тестировать каждый раз глупо по экономическим причинам.
                                        • UFO just landed and posted this here
                                            +2
                                            Сначала попробуйте эрланг :)
                                              –1
                                              > идеальную, проверенную универсальную платформу, благодарную во всех отношениях

                                              питоноёб детектед
                                                +6
                                                да ну не бывает «идеальных универсальных платформ хороших во всех отношениях». нету серебряной пули. пхп говно полное. питон говно. эрланг говно. го говно. си плюс плюс говно. ассемблер говно. си говно. си шарп говно. джава ваще говно. хаскель говно. лисп говно. окамл говно. схеме говно. эф шарп говно. немерле говно. вижуал бейсик говно. вижуал фортран говно. просто фортран говно. кобол говно. ада говно.

                                                так, что я забыл?

                                                у каждого решения есть плюсы и минусы. у каждого. нет ничего идеального. нет «универсального» решения. нет «идельного». нету никаких «благодарную во всех отношениях». если кто-то заявляет обратно, нужно его бить по голове.
                                                  +1
                                                  обджектив си говно. паскаль говно. перл говно. лого говно.
                                                    +4
                                                    Хватит срать в камменты.
                                                      +1
                                                      я пытаюсь доходчиво объяснить человеку, что у всех языков есть недостатки. к сожалению, я не оратор, и возможно выбранный мной способ плох. если знаете лучше — вы можете написать сообщение пользователю Jazzist.
                                                        +1
                                                        Нет плохих инструментов. Есть плохие программисты.
                                                        Нет хороших инструментов. Есть хорошие программисты.
                                                        Есть только один инструмент — нет программиста.
                                                    +1
                                                    JavaScript, Java Script забыли!!!
                                                      +1
                                                      И то же самое другими словами: tonsky.livejournal.com/281876.html
                                                    +1
                                                    Питон не даст как минимум одного — нормального production-решения для закрывания исходников и лицензирования коробочных продуктов, по крайней мере так было 4 года назад, когда мы начинали писать Мегаплан.
                                                      –1
                                                      Не соглашусь. Можно pyc-и выкладывать.
                                                        +2
                                                        я не очень в этом силён, но насколько я помню, pyc очень легко конвертируется назад в код с помощью чуть ли не встроенных средств питона
                                                    • UFO just landed and posted this here
                                                        0
                                                        Всё верно, но в российских реалиях пока что одним SaaS'ом сыт не будешь.
                                                        0
                                                        Если вам всерьёз (зачем-то) нужно закрывать исходники программы, бинарники которой будут у пользователя, то весьма большое подмножество Python-а можно компилировать Cython-ом.

                                                        А на практике, мне вот с лёту не удалось найти рабочий способ, способный декомпилировать .pyc-шки (не говоря уже про .pyo-шки) моего рабочего проекта. depython.com, depython.net/, svn-овый UnPyc на них падают (http://crazy-compilers.com/decompyle по ряду причин не проверял ;) ). И это Python 2.6, даже не 2.7…
                                                        +1
                                                        У питона тоже есть проблемы.
                                                        1) проблемы с лёгкими тредами
                                                        Ок, мы можем решить их с помощью gevent, но тут…
                                                        2) отсутстие ОТР
                                                        … приходится велосипедить всю ту отлаженную инфраструктуру, что уже есть в эрланг/ОТР. Супервизоры, behaviours, gen_server и т.д. При этом всё это в отсутствии настоящей конкурентной многопоточности — если один гринлет блокируется, блокируются все.
                                                        • UFO just landed and posted this here
                                                            0
                                                            А, ну конечно. Всё можно написать на ассемблере-ла-ла-ла. Это не аргумент.
                                                        –1
                                                        Может вместо того, чтобы писать фреймворки, конвертеры, адаптеры для PHP, просто изучить и использовать полноценный язык?
                                                          –3
                                                          Я вот тоже автора не понял, он не захотел использовать одни кастыли, а взял другие, помощьнее.
                                                          А почему бы просто не взять и не переписать на языке и технологии в котором всё это давно решено и удачно: Java, Ruby, C# и т.п.
                                                            +2
                                                            Я ж написал, что переписывать — не вариант.
                                                              –1
                                                              Вы искренне надеетесь поставить на гребную галеру атомный реактор и паровую турбину, причём прямо на ходу? Бог в помощь…
                                                              0
                                                              третий абзац сверху вроде как достаточно полно отвечает на этот вопрос.
                                                              • UFO just landed and posted this here
                                                                  0
                                                                  возможно он его просто не прочитал :)
                                                            0
                                                            с одной стороны, для данной конкретной задачи Gearman подходит лучше. с другой стороны, выбранная вами модель позволит безболезненно постепенно (при необходимости) перепиписывать приложение на эрланг.
                                                            довольно необычное решение. и вроде не костыльное.
                                                              +5
                                                              Чудовищно, если честно.

                                                              Остается ощущение, что автор намеренно путает понятия «язык программирования», «ОС», «платформа» и еще десяток.

                                                              Скажите пожалуйста, а почему PHP, как язык, должен вообще что-то знать о Вашем желании запустить программу в определенное (или через определенное) время? Вам не приходит в голову, что для этого нужно просто грамотно пользоваться средствами операционной системы, которая умеет это давно и хорошо?

                                                              Ровно такой же вопрос по поводу Windows — PHP не должен вообще знать о Ваших половых трудностях с платформой.

                                                              Ну и конечно вызов скрипта планировщиком по HTTP — это классика жанра, браво. Жду тему «как мы подняли производительность в 2 раза, отказавшись от HTTP при вызове скрипта с того же сервера».

                                                              Налицо попытка решить архитектурные проблемы костылями.
                                                                +1
                                                                Вы вообще читали пост?

                                                                У операционных систем нет единого способа запустить задачу в указанное время.
                                                                  +2
                                                                  Вы вообще читали хоть что-то?

                                                                  cron и at — вполне себе кроссплатформенны
                                                                  это раз

                                                                  Второе — пусть даже есть определенные различия между cron и nncron. Так напишите адаптер, е-мое, общий-то принцип одинаков.

                                                                  Зачем тащить еще один язык просто для запуска задачи?
                                                                    +1
                                                                    В отличие от вас, я ещё и много писал, посложнее чем цмс-ки на пхп. И деплоил софт под виндой, делал коробку которая развертывается потом у кучи разных, среднеквалифицированных людей.

                                                                    Людям нужно наиболее безгеморойное решение целого класса задач. Erlang — лучшее решение, которое дешевле всего с точки зрения последующей поддержки.

                                                                    Вы же предлагаете онанизм в виде дополнительных строк пользовательской документации «поставьте это, следите за этой программой».

                                                                    В их случае ни за чем вообще администратору коробки следить не надо будет.
                                                                      +2
                                                                      Я, в общем-то CMS не пишу достаточно давно.
                                                                      А то, что писал — не считаю стыдным, Вы же не стыдитесь того, что когда-то с увлечением изучали букварь?

                                                                      Я предлагаю пользоваться средствами ОС там, где они нужны.
                                                                      Или искать косяки в архитектуре проекта.
                                                                        0
                                                                        Ваше предложение неуместно: в операционных системах _нет_ единого средства для указанных задач.
                                                                        Значит надо носить своё. Возвращаемся к пункту про поддерживаемость.
                                                                      +3
                                                                      Мы сейчас как раз используем nncron в качестве подпорки для Windows. Это неудобно.

                                                                      Суть идеи в том, чтобы вместо того, чтобы для каждой задачи таскать своё решение, взять одно решение — Erlang — и сделать всё на нём.

                                                                      Было бы совсем замечательно, если бы можно было всё сделать на самом PHP и не думать о других решениях, но, мне кажется, я достаточно подробно описал, почему PHP плох для целого ряда задач.
                                                                        –1
                                                                        Что всё сделать на PHP?

                                                                        Диспетчер очереди сообщений?
                                                                        Аналог cron-а?

                                                                        Зачем?

                                                                        Есть готовые и проверенные временем решения, встроенные в ОС. То, что Вы не умеете пользоваться cron-ом либо планировщиком Windows, не значит, что надо писать свой планировщик.

                                                                        То, что Вы не умеете пользоваться CLI в PHP — не значит, что Ваши программы надо запускать исключительно по HTTP.

                                                                        И так далее.
                                                                          0
                                                                          Диспетчер очереди сообщений?

                                                                          я не предлагаю делать диспетчер на PHP, я предлагаю использовать одно из лучших решений на рынке, написанный на Erlang — RabbitMQ

                                                                          Аналог cron-а?

                                                                          Он у нас уже есть, поскольку сам крон не умеет решать задачи типа «сделать что-то каждую вторую пятницу чётного месяца в 11:00», а нам это нужно.
                                                                          На Erlang нужен только инициатор, который вовремя запустит PHP.

                                                                          То, что Вы не умеете пользоваться CLI в PHP — не значит, что Ваши программы надо запускать исключительно по HTTP.

                                                                          А что там, собственно, нужно «уметь»? Мы сейчас используем запуск задач по cron. Могу сказать, что это неудобно как минимум тем, что трудно контролировать количество таких задач, работающих в данный момент — довольно просто себя задосить.

                                                                          Что касается производительности — я не проводил бенчмарков, а вы проводили? Откуда информация, что запуск через HTTP+FastCGI будет работать дольше, чем через прямой CLI вызов? Как мы все знаем, FastCGI для того и придумали, чтобы не разбазаривать ресурсы на постоянный fork при использовании CGI.
                                                                            –1
                                                                            Теперь я понимаю, почему только за прошлый месяц у меня на собеседовании были 2 Ваших программиста…
                                                                  +2
                                                                  К тому же я не уверен, что на JVM можно элегантно решить проблему масштабного comet'а.
                                                                  Чтобы развеять сомнения, посмотрите Netty.
                                                                    0
                                                                    или на худой конец Scala/Akka — будет то же, за что хотите ерланг. А вместо RabbitMQ логично взять HornetQ
                                                                      +1
                                                                      Меня искренне забавляют предложения заменить отлаженную, компактную и проверенную временем инфраструктуру на сырые академические поделки типа Akka.
                                                                      Зачем??
                                                                        0
                                                                        есть такая пословица — каждый кулик хвалит свое болото :) То что вы пиарете ерланг, конечно все круто, но не значит, что идеальная система. Пруфлинк плиз про сырость акки :) При этом получая все из мира java а не несколько десятков странно написаны непонятных модулей и всего 2 — 3 реально работающих продукта в мире. Это как говорит о платформе?
                                                                          +1
                                                                          Буквально недавно мой бывший однокурсник нашел в скаловском unlink-е утечку памяти. Стоит ли дальше продолжать насчёт сырости продукта?
                                                                            +2
                                                                            Ну всё же менять RabbitMQ на что-то другое я бы не стал, его можно отлично использовать и с Java/Scala решениями, тем более, что у него есть официальное Java API.

                                                                            Erlang и решения на нём — штуки отличные, поэтому я с удовольствием использую их (CouchDB, Riak, RabbitMQ) из других языков/платформ, совсем не обязательно для этого погружаться в «кухню» эрланга конечно же.
                                                                              0
                                                                              да, соглашусь, Riak достаточно хороший и интересный.

                                                                              Да, верно, я упустил о Java API, правда мне кажется оно все же работает через сеть.
                                                                      0
                                                                      Для данной задачи хорошо подходит Node.JS/npm. Работает и под Windows, и прекрасно подходит для Comet и имеет неплохие клиенты для очередей и нереляционных баз данных.
                                                                        0
                                                                        + Redis
                                                                          0
                                                                          > Для данной задачи хорошо подходит Node.JS/npm. Работает и под Windows, и прекрасно подходит для Comet и имеет неплохие клиенты для очередей и нереляционных баз данных.

                                                                          И отлично падает на сраных 100k сообщениях — github.com/Papipo/socket.io-erlang-vs-nodejs
                                                                            0
                                                                            У кого-то на машине :)

                                                                            Кстати, ничего не мешает добавить Cluster, чтобы распаралеллить на все ядра.
                                                                              0
                                                                              Простите, я не знаю что такое Cluster, но я знаю правильный вопрос — а оно умеет общаться между процессами работающими на разных ядрах (shared state, messaging)? А между процессами на разных машинах?
                                                                                  0
                                                                                  Т.е. не умеет.
                                                                                    0
                                                                                    Умеет, стандартные сообщения Web Workers никто не отменял.

                                                                                    просто для меня ZeroMQ предпочтительней, ибо при этом границы процессов и машин расплываются.

                                                                                    Почитайте про эту технологию, это нормальный нативный код, так что производительность на хорошем уровне.
                                                                                      0
                                                                                      Акжан, тебе явно стоит поработать там, где есть продакшн =)))
                                                                                      Люди хотят оставить один процесс, а ты предлагаешь целую пачку и ещё дать им возможность общаться через дополнительный демон. Очень весело это всё будет развертываться на клиентской винде.
                                                                                        0
                                                                                        Максим, у нас для большинства проектов есть и staging, и production :)

                                                                                        ZeroMQ — библиотека, предоставляющая транспортный слой (сообщения внутри процесса, вне процесса, вне узла сети), а не демон. Это не RabbitMQ etc.

                                                                                        Автор хочет внедрить прослойку в виде Erlang, я в его случае мог бы заменить на прослойку в виде Node.JS.

                                                                                        P.S.: кстати, потихоньку читаю по Erlang, восхищаюсь местами :)
                                                                              0
                                                                              это трабла именно либы Socket.io а не ноды
                                                                                0
                                                                                там ничего не падает, там проблема с тем, что для websocket transport'а не совсем правильно реализована поддержка «сердцебиения» из-за чего закрывается соединение. Если отключить поддержку сердцебиения (а в erlang'овской реализации ее кстати и нет), то все нормально работает:

                                                                                twitter.com/#!/3rdEden/status/74884695933980673
                                                                                twitter.com/#!/3rdEden/status/74879359017680896

                                                                                –1
                                                                                Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем server-side JS и node.js, ведь мы уже знаем JS.
                                                                                  0
                                                                                  а вы действительно не научились еще программировать без паттерн-матчинга, без статическиз типов (а я так рад что слез с этой фигни)?
                                                                                    –2
                                                                                    А вы действительно не научились ещё программировать в ластах стоя в гамаке?
                                                                                    0
                                                                                    Erlang у нас тоже используется, но не для Comet-сервисов.

                                                                                    Кроме того, хоть по многим факторам Node.JS уступает Erlang, не стоит забывать, что область применения все-таки отличается. А некоторые перечисленные вами возможности давно есть для Node.

                                                                                    Так что ваши предпосылки неверны.
                                                                                      –1
                                                                                      >некоторые перечисленные вами возможности давно есть для Node
                                                                                      Подробнее же!
                                                                                      >область применения все-таки отличается
                                                                                      >некоторые перечисленные вами возможности
                                                                                      >Так что [все] ваши предпосылки неверны.
                                                                                      У вас ошибка в кванторе.
                                                                                        0
                                                                                        Основная ваша предпосылка — «потому что мы знает JavaScript». Ну да, знаем :) Но это не основная причина :)
                                                                                          0
                                                                                          Ну а тогда нет ни одной причины взять ноду вместо эрланга. Я допускаю, конечно, что это может быть не так, но никто до сих пор не смог привести ни одного аргумента нормального кроме «JS все знают». Это неправда, сервер-сайд JS гораздо сложнее того, что под ним подразумевает большинство верстальщиков со своими «вау-вау, я подключил плагинчик на jquery, теперь я погромист». Совсем не в последнюю очередь из-за граблей, заботливо разложенных самим языком — см. wtfjs.com хотя бы.
                                                                                            0
                                                                                            Это смотря с какой стороны посмотреть. Часто Erlang не нужен просто.

                                                                                            Поймите, я не фанат какой-либо техники :) Чем удобнее воспользоваться в конкретном случае, тем и пользуюсь, в каждом конкретном случае.
                                                                                      0
                                                                                      Боюсь, что я даже не смогу перечислить все используемые нами языки, каркасы, и т.д… В них входят и ObjectiveC/MLFoundation, и Erlang/OTP, и Node.JS, и Rails, и Sinatra, и nginx/Passenger/unicorn/rainbows/Apache/Mongrel, и C++/boost, и Perlbal, и что-то еще… Зоопарк еще тот :)
                                                                                        0
                                                                                        Забыл, еще PHP и .NET используются плотно :)
                                                                                    +3
                                                                                    По делу могу вот что добавить:

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

                                                                                    FastCGI я бы порекомендовал под MIT выложить на гитхаб, это инфраструктурная вещь, которую лучше пусть будут отлаживать другие люди.

                                                                                    С остальным успехов, через пару недель вы уже сможете собрать работающий прототип.
                                                                                      0
                                                                                      Спасибо на добром слове. Осталось только найти разработчика, который это сделает.
                                                                                      +1
                                                                                      Для поддержки коробочного решения (и, соотвественно, решения проблем с кроcсплатформенностю) очень бы подошла технология виртуализации. Тогда коробочное решения представляло бы из себя виртуальный диск, со связкой необходимого и настроенного ПО.
                                                                                        0
                                                                                        Тоже об этом думал. решение простое и изящное. И требования кроссплатформенности и т.п. сразу отпадают, можно заточить строго под одну конфигурацию.
                                                                                        • UFO just landed and posted this here
                                                                                          0
                                                                                          Мы рассматривали этот вариант.

                                                                                          Тогда нужно завязывать лицензию на hardware-ключ, а такого решения для PHP нет.
                                                                                            0
                                                                                            Его можно реализовать в виде встроенного PHP модуля. На мой взгляд это сделать проще, чем найти адекватного Erlang программиста.

                                                                                            А в общем придумывать ничего не нужно, так как готовые решение уже, в принципе, имеются: www.microcosm.com/dongle_php_protection.php
                                                                                              0
                                                                                              хорошая шутка. Запрограммировать linked-in php модуль и потом его сопровождать проще, чем найти erlang программиста.
                                                                                                0
                                                                                                И что там сопровождать?
                                                                                          –1
                                                                                          Даже пожалел на минуту, что к вам работать не пошел, когда звали.
                                                                                            0
                                                                                            наши двери по-прежнему открыты для хороших разработчиков :)
                                                                                            +4
                                                                                            Из того, что может вам пригодиться:

                                                                                            Для связки Erlang с PHP помимо классических cli и FCGI/HTTP можно попробовать воспользоваться erlang ports www.erlang.org/doc/tutorial/overview.html. Не знаю, насколько это разумная идея, но если удастся запустить — будет очень удобно работать. Для ports есть C-биндинг, соответственно можно написать PHP-шное расширение и на порядок упростить процесс взаимодействия Erlang и PHP. Но тут нужно покопать конечно хорошенько предварительно.

                                                                                            Для Comet можно попробовать socket.io-erlang github.com/yrashk/socket.io-erlang. Разрабатывается хабраюзером yrashk. Говорят, очень годная вещица.

                                                                                            Nginx можно повесить разве-что на поддомене или на другом порту, ибо Comet он не умеет проксировать. Хотя для коробочного решения Nginx, пожалуй, это лишнее.

                                                                                            Еще плюс — вы сможете ВСЕ ваши Erlang приложения запускать (и останавливать/перезапускать) в одном Erlang процессе, вместе с RabbitMQ Yaws/Mochiweb и собратьями. Своего рода операционная система в миниатюре.
                                                                                              0
                                                                                              Спасибо. Приятно видеть, что идея понятна не только мне.
                                                                                            • UFO just landed and posted this here
                                                                                                +1
                                                                                                Легче вам начать самим писать, эрланг можно за 2-3 недели подучить и на достаточно адекватном уровне уже понимать и писать.

                                                                                                Найти эрлангиста сложно и их могут переманить в какие-то штуки типа эхи, хероку или мочимедии) На прошлой работе часть (достаточно некритичная) была реализована на эрланге специально нанятым человеком, а потом его сманили. Дима, Привет! =)

                                                                                                А те люди которые были достаточно хороши, чтобы разобраться и поддерживать его код были итак нагружены на 100% и в итоге решение застопорилось на той стадии развитии, на которой было оставлено)
                                                                                                  +4
                                                                                                  >В данной статье я исхожу из того, что долгоиграющие процессы в PHP — это исключительно ненадёжный костыль, под который нужно подставить ещё один костыль, чтобы оно как-то жило.
                                                                                                  не верная гипотеза приводит к неверным результатам…

                                                                                                  >Не вселяет оптимизма даже то, что в PHP 5.3 вроде появился нормальный сборщик мусора.
                                                                                                  потому что не умеете его использовать? ваш код изобилует ооп ради ооп? приведу пример схожий, pconnect почему не используется повсеместно — да просто потому что нужно делать free постоянно, так вот в php есть unset!

                                                                                                  >Не убеждает и phpDaemon, который многим нравится, но завязан на libevent, поэтому под Windows работать не будет.
                                                                                                  простите а это что vladimirbarbarosh.blogspot.com/2011/05/compile-php-536-pecl-libevent-004.html?

                                                                                                  >На текущий момент не существует нормального нативного и, главное, надёжного способа «демонизации» программ на PHP.
                                                                                                  php demon.php & — не работает хотите сказать :)

                                                                                                  >И даже если пытаться переходить на тру FastCGI, всё равно над этим хозяйством нужен диспетчер, который будет регулярно процесс перезапускать. Короче, на мой взгляд, единственным продакшн-режимом работы PHP является классический FastCGI (или apache+prefork+mod_php под unix-like системами).
                                                                                                  диспетчер нужен только в случае если процесс упал с концами, вообще не понимаю почему вы пытаетесь применить одну и туже логику запуска приложений для коротко и долгоживущих процессов?

                                                                                                  >Думаю, многие разработчики, которые писали на PHP чуть больше, чем «Hello World!», сталкивались с проблемой отложенного запуска
                                                                                                  логика другая, оба ваших решения не верные потому что вы рассматриваете php как приложения которые выполняются меньше 30 секунд, внесу ясность:
                                                                                                  решение через эрланг:
                                                                                                  — пхп скрипт отправляет в событие
                                                                                                  — ерланг выбирает из очереди событие
                                                                                                  — пхп запускает событие
                                                                                                  решение через пхп:
                                                                                                  — пхп скрипт отправляет в событие
                                                                                                  — пхп выбирает из очереди событие
                                                                                                  — пхп запускает событие
                                                                                                  в чём разница — принципиально не в чём, просто в первом случае постоянно запущен эрланг, во втором php

                                                                                                  >Все новомодные вкусные вещи типа long-polling, websockets и т.п., конечно, можно сделать и на чистом PHP, но вот только ценой целого долговисящего php-процесса на каждое соединение
                                                                                                  поддерживать 1000 соединений одновременно для 1 php процесса не проблема (смотрим на select функции), проблема в том как их обрабатывать одновременно

                                                                                                  >...cron...
                                                                                                  пока из php не удалили ticks — можно писать просто отличные планировшики

                                                                                                  к чему я всё это — алгоритмы примерно одинаковые во всех ЯП и реализации тоже примерно одинаковые, просто нужно уметь пользоваться всем богатством ЯП на котором пишешь, в моем случае это php.

                                                                                                  ps erlang = awesome, концепция ЯП просто убойная, для себя нашёл просто кучу отличных идей которые перетащил что смог в php, а let it crash — считаю лучшей методологией для программирования
                                                                                                    0
                                                                                                    не верная гипотеза приводит к неверным результатам…

                                                                                                    Если исходить из того, что гипотеза не верна, то, конечно же, во всём остальном я с вами соглашусь. Но заметьте, что вы первый, кто поставил её под сомнение. Такая у PHP репутация нехорошая, и, поверьте, она не на пустом месте.
                                                                                                    Я не доверю интерпретатору PHP длинные задачи, не буду делать так, чтобы от стойкости php-процесса зависела надёжность всей системы. Не предназначен он для этого. Скорее всего, даже разработчики самого PHP вам скажут то же самое.

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

                                                                                                    простите а это что vladimirbarbarosh.blogspot.com/2011/05/compile-php-536-pecl-libevent-004.html?

                                                                                                    Это какой-то кул-хацкер на коленках что-то скомпилировал. От этого ни phpDaemon, ни php-fpm Windows поддерживать не начали. Но спасибо за наводку, libevent под винду есть — значит не всё потеряно :)
                                                                                                      +2
                                                                                                      >Но заметьте, что вы первый, кто поставил её под сомнение.

                                                                                                      По-моему, достаточно мало людей, которые хотя бы пытались писать полноценные демоны на современном PHP и могли бы аргументированно опровергнуть вашу гипотезу. В большой степени это действительно объясняется репутацией, стереотипами и прочим недоверием, основанных на реальных проблемах в ранних релизах. Но вот в последнее время не встречал объективной критики типа «написали демон на PHP 5.3.2, через день работы и обработки 100500 запросов съел 10Гб ОЗУ и свопа, после чего умер/завис. Вот код — ЧЯДНТ?». То есть аргументированного подтверждения вашей гипотезы тоже нет. Или вы проводили такую работу/исследования/поиски и у вас есть факты, что современный PHP всё ещё не подходит для грамотной разработки демонов? Или, всё же, решение искать альтернативу основано на репутации языка (пускай и справедливо заслуженной когда-то), а не фактах?
                                                                                                        0
                                                                                                        *5.3.3
                                                                                                          +2
                                                                                                          Возможно немного переведу тему, но…
                                                                                                          То что никто не пытается писать демонов на PHP — это не оправдание PHP и не повод попробовать взять и написать.
                                                                                                          Ведь под PHP есть и к GTK библиотеки, но PHP-GTK приложения можно по-пальцам пересчитать.

                                                                                                          Вот думаешь — на чем написать GUI-приложение. Набиваешь GTK-python. Тебе 100500 статей с HappyStories, туториалов, рецептов. В репозиториях половина десктопного софта на питонах. Ну и естественно будешь новый проект на нем писать.

                                                                                                          Хочешь написать отказоустойчивый сервер. Набиваешь Erlang Server. Там тебе «A Million-user Comet Application with Mochiweb», множество историй, рецептов, примеров… Какой вывод?

                                                                                                          Есть конечно исключения, но на то они и исключения!

                                                                                                          Т.е. инфраструктура есть, есть куча историй с Happy End. А становиться пионерами редко кто хочет.
                                                                                                            +1
                                                                                                            А откуда взялись инфраструктура и success story? Кто-то рискнул стать пионером и поделился опытом. Я вовсе не призываю писать демонов на PHP, но вот откидывать такой вариант только из-за «репутации» как-то не объективно, по-моему. Мне тоже хочется написать что-то на Erlang и интуитивно чувствую, что результат будет лучше, но утверждать что он лучше только потому у PHP «плохая карма» я не буду, даже в качестве гипотезы. Напишу прототипы, погоняю их в разных условиях и там буду принимать решение, причём не исключаю, что оно окажется ошибочным из-за слишком большой степени упрощения и допущения прототипов, да и просто из-за моей криворукости.

                                                                                                            Доводы вида «Для Erlang/Python есть такая-то инфраструктура, поддерживаемая тысячами разработчиков и не только just for fun, а для PHP её нет или есть, но поддержка производится единицами и из любви к искусству» легко проверить и более-менее объективно оценить их влияние на конечный результат. А как оценить влияние на проект «репутации» я не представляю, по крайней мере с технической точки зрения.
                                                                                                              0
                                                                                                              Многие библиотеки PHP просто не тестировались в долгоиграющем окружении, а тестировать их придется первопроходцу.
                                                                                                            0
                                                                                                            Нет, специальных исследований с стресс-тестов для PHP 5.3 я не проводил. Есть только опыт того, что даже в fastcgi иногда приходится всё перезапускать, чтобы оно вздохнуло. Правда больше у нас работал 5.2, но и с 5.3 в последнее время возникают инциденты.

                                                                                                            Ну как косвенный аргумент можно привести наличие переменной PHP_FCGI_MAX_REQUESTS или настройки pm.max_requests? В эрланге ничего подобного нет.

                                                                                                            Наверное, если бы я был снова студентом и у меня была куча времени на различные интересные исследования, я бы рискнул попробовать писать на PHP всё подряд. Но, видимо, я старею, и начинаю тянуться к надёжности :)
                                                                                                              0
                                                                                                              Вот если бы хотя бы вкратце описали инциденты с 5.3 — гипотеза выглядела бы куда более убедительной. Пускай даже на уровне «мы решили не разбираться в чём конкретно проблемы и как их можно исправить или обойти, а решили взять за основу язык/платформу в котором отсутствие этих проблем декларировано и случаев нарушения этой декларации за 10 минут гугления выявлено не было» :)
                                                                                                        +1
                                                                                                        Для частичного решения ваших проблем подойдет Celery. Это система асинхронного выполнения различных задач, в т.ч. периодических (как cron).
                                                                                                        Она как раз использует RabbitMQ в качестве бэкенда и замечательно зарекомендовала себя при работе с python и django.

                                                                                                        У нас система на Celery + RabbitMQ полностью заменила cron, добавила возможность
                                                                                                        наблюдать за всеми, происходящими асинхронно, джобами, а также добавила много
                                                                                                        интересного функционала в web-приложения, например, позволяя запускать задачи и не ждать
                                                                                                        их выполнения во время генерации ответа на HTTP запрос, а запрашивать ответ позже,
                                                                                                        через ajax.

                                                                                                        Не так удобно будет ее использовать с PHP, как с Python (так как там есть встроенная
                                                                                                        поддержка django и других фреймворков), но все же это вполне нормальный usecase.

                                                                                                        В общем, я советую вам взглянуть в сторону Celery, хотя бы чтобы иметь представление о возможности. Будет больше информации для принятия решений.
                                                                                                          0
                                                                                                          Celery весьма и весьма интересная штука, у нас тоже используется с Pylons. Из плюсов: очень простое API и хорошая интеграция с фреймворками, плюс очень сильный ВАУ-эффект (типа «как я жил без этого раньше?») НО:
                                                                                                          1) У меня почему то часто появляются Zomby — процессы. Иногда пул воркеров намертво зависает.
                                                                                                          2) Применительно к статье Celery — это необходимость завязки на Python и необходимость держать MQ демона. Для коробки усложняется установка, настройка и поддержка.
                                                                                                          3) Все-таки до Erlang ему далеко. Честно. В erlang есть коммуникация между «тасками» (в Celery они довольно-таки изолированные) и можно запускать задачи тысячами (в Celery больше 20-30 воркеров не запускают на одной машине) и еще куча всего интересного.
                                                                                                          В минусы Erlang пожалуй сложнее или непривычнее описывать нетривиальную логику, но тут мнения могут не совпадать.
                                                                                                            0
                                                                                                            Спасибо за наводку, посмотрю.
                                                                                                              0
                                                                                                              Пробовал эту celery на достаточно ненагруженном проектике (десяток воркеров лопатят круглые сутки примерно по таске в секунду).

                                                                                                              Не советую!

                                                                                                              То воркеры зависают, то память кончается, то выходит очередная новая версия celery с парой пофикшенных багов, а заодно и с новым (несовместимым) форматом конфига.

                                                                                                              В результате оказалось проще выкинуть celery и самолично написать на базе Redis и сотни строк питонячего кода простую систему очередей, коя и работает у меня уже больше полугода без единого зависания.
                                                                                                              –4
                                                                                                              Соглашась с многими отписавшимся, что лучше все-таки переписать код на новый фреймворк, ведь все алгоритмы есть, и реализовать их уже на конкретном языке не проблема.
                                                                                                              От себя посоветую node.js который успешно работает с потоками, да и к тому же не надо ничего знать кроме javascript… А в данном случае нужно еще php и erlang. Зачем три языка там где можно использовать один?
                                                                                                                0
                                                                                                                1. Самый главный аргумент, почему это не будет работать: тест скорости параллельной записи и чтения событий с php в RabbitMQ показывает дико медленные числа. Порядка 3000-5000 записей+чтений в секунду на одной мощной тачке. Поэтому все возможности ребита по обработке 200.000-800.000 сообщений в секунду из-за оверхеда в php extension полностью исчезают. Банальная очередь на Redis'е большие числа дает (но, разумеется, в ней нед подписки). Прежде, чем писать статьи и грозные комменты к статье — померьте скорость :)

                                                                                                                Если и выбирать для пхп сервер очередей — то не RabbitMQ, а что-нибудь другое. Это слишком глючная, тормозная и не рабочая связка. И конечно ребит ничем не лучше другого софта — при избытке непрочитанных сообщений уходит в своп и жестко сыпится.

                                                                                                                2. Я может плохо читал… но на Эрланге есть готовый веб-сервер. Там один процесс (эрланга) держит один коннект. Все велосипеды собственно придуманы и реализованы много лет назад. Используйте его. Нафига городить огород с ПХП, понять не могу?

                                                                                                                3. Как-то однобоко описана проблема крон скриптов. У нас имеется большой пул application-серверов и такой же большой пул cron-серверов. Но не в том смысле, что вы подумали! Как устроены крон скрипты:
                                                                                                                а) это обычные php скрипты, работающие в среднем по 10 минут
                                                                                                                б) по факту, никаких утечек памяти в пхп нет, даже если циклом создавать и уничтожать миллиард объектов (но они могут быть, поэтому скрипты, на всякий случай, дольше 10 минут не работают)
                                                                                                                в) все скрипты всегда запущены… например, под задачу «А» всегда запущены 5 копий одного скрипта
                                                                                                                г) когда крон-менеджер решает, что текущий скрипт превысил 10 минут, тот завершается, мгновенно запуская свою копию (т.е. никаких ожиданий 1-59 секунд от системного crontabа нет, последний нужен только, если скрипт свалится в корку и при перезагрузке всего сервера)… разумеется, прогнозируя свое скорое завершение, скрипт перестает принимать новые данные и обрабатывает накопленные
                                                                                                                д) cron-скрипт ничем не отличается от application-скрипта, только первый принимает события из очереди (memcacheQ / redis), а не от веб-браузера

                                                                                                                В итоге выходит полная эмуляция демонов и прочей ненадежной фигни штатными простыми средствами с обычной логикой приложения.

                                                                                                                4. В задачах, когда бразуер очень часто должен получать данные (чат, онлайн мессенджер) существуют модули под nginx для доступа к memcacheD и memcacheQ. Пришел AJAX запрос, nginx отправил его в свой модуль (написан на С), тот принял постом данные от браузера и отправил сообщения в очередь, одновременно в JSON виде ответил браузеру, прочитав заранее подготовленный ключ в memcacheD. Все это без пхп! Не нужно никакой мути в виде демонов и комитов. Все запросы на чтение данных («нет в ли чате новых сообщения?») приходят в браузер минуя пхп полностью! Пхп занимается лишь приемом новых текстовых сообщений от человека в чат + разбором очереди от браузера (тот отчитывается, что жив, читает сообщения и т.д. — через очередь). И разумеется фоновые крон-скрипты (по методологии выше) занимаются формированием нужных ключей в мемкеше, которые запрашиваются браузером. Например, пришло новое сообщение в чат — нужно модифицировать десяток-сотню ключей в мемкеше для всех пользователей, которые сидят в этом чате. После этого не важно — будут те ключи читаться браузером или нет. Мы их один раз сформировали и до нового текстового сообщения ничего не делаем.

                                                                                                                Ни одного лишнего компонента не используется, кроме традиционных php-fpm, nginx, модуль к nginx, memcache.
                                                                                                                  0
                                                                                                                  Насчёт 4) можно уточнить? А как гарантируется, что каждое сообщение будет прочитано каждым получателем? Или просто старые сообщения вытесняются в мемкеше, подразумевая, что они никому уже не интересны?
                                                                                                                    0
                                                                                                                    По аналогии работает правильный чат на php. Есть демон для доставки сообщений пользователем, а php просто подсовывает ему новые сообщения.
                                                                                                                      0
                                                                                                                      Меня заинтересовало как реализовано
                                                                                                                      Все запросы на чтение данных («нет в ли чате новых сообщения?») приходят в браузер минуя пхп полностью!
                                                                                                                      если новые сообщения в мемкэше были, но были или вытеснены, или просто стерты при рестарте.
                                                                                                                      +1
                                                                                                                      Гарантируется тем, что JS браузера будет каждые пару секунд долбиться в nginx (т.е. в свое персональное memcache поле) и читать от туда пачку последних сообщений. Если он не обратился туда — его проблема. Если браузер подвис и при очередном чтении в поле обнаружил пропуск данных — идет инициализация всего списка сообщений. В общем есть 2 четких стадии: инициализация при первом входе (выполняется пхп), поддержания актуальности при живом окне браузера с JS (nginx+memcache).

                                                                                                                      Если делать тоже самое на очередях, то будет так: мы кинули важное сообщение в очередь, браузер прочитал его, связь накрылась, данные не пришли (и с сервера очередей оно удалено). При повтором чтении данных уже не будет. Это небольшая проблема. А если же эти данные, но с избытком (т.е. с небольшим списком более старых сообщений) просто положить в поле мемкешу — то будет не важно, сколько раз его прочитает браузер. Они «потеряются», только если появятся более свежии данные (сообщения), вытесняющие старые. В таком подходе все четко делится на не связанные между собой компоненты проекта.
                                                                                                                        0
                                                                                                                        Спасибо. Как-то стадию «инициализация при первом входе (выполняется пхп)» я не заметил. И что браузер должен проверять пропущенные сообщения тоже не понял.
                                                                                                                    +2
                                                                                                                    Похоже, Фабьен прочитал эту статью
                                                                                                                    twitter.com/fabpot/status/75524423599403008
                                                                                                                      0
                                                                                                                      Я тоже удивился, когда этот твит Фабьена увидел. Не иначе ноосфера.
                                                                                                                        0
                                                                                                                        :) забавно
                                                                                                                        0
                                                                                                                        Совсем недавно скрипт на php у нас плодотворно работал 2 недели нон-стоп — конвертил огромную базу. Поначалу валился, упираясь в память, пока не переписали с применением форков для обработки данных пачками.

                                                                                                                        Only users with full accounts can post comments. Log in, please.