>phpFastCGI — правильная реализация FastCGI, которая позволяет добиться немыслимой производительности.
всякое подобное утверждение должно подкрепляться цифрами и фактами
кроме голословных утверждений с статье ничего нет.
а можно использовать OpenMP без Visual Studio
я сторонник Unix технологий
>При этом вычисление пароля вторым методом, на моем компьютере, выполнялось значительно быстрее.
желательно такие заявления подтверждать цифрами. что стоит запустить таймер перед вычислениями и остановить после.
И еще посторить 10-100 итераций для усреднения…
>А идея про Connection pool звучит очень заманчиво!
я давно думаю над пуулом (MySQL + PHP ), но я не спец по Ораклу и ничего сказать не могу.
из моих исследований по MySQL, хотел сделать демон, который бы раздавал коннекции РНР-вокерам через shmem
но наткнутся на sigfault, для ликвидации которого надо было переписать более 33% кода mysqlclientlib Сизыфов труд.
как вариант — сделать демона, который запускал бы n MySQLClient вокеров, которые постоянно держали бы коннекцию с мускулем, но в этом случае при обмене из PHP, мы клали бы в shmem запрос, оповещали демона и ждали бы оповещения выполнения запроса, после этого брали данные из shm, формировали массив и возвращали в РНР код. т.е. по сути написал бы свою новую либу, а хотелось совместимости.
В общем, история про пул — это на какие грабли мне пришлось наступать и куда копать дальше.
Вам тоже спасибо, давно искал сравнительные характеристики nginx & lighttpd (про lighttpd2.0 узнал из комментов этого блога)
посмотри в сторону использования шаред мемори и libevent
это должно быть быстрее чем fastcgi
(будет время, сам покапаю в эту сторону)
мне тоже нужно будет запускать не легкие процессы…
собственно почти тоже самое я написал ниже немного иными словами.
имел небольшой опыт использования логики модулей, отказался из-за указанных catap причинами.
проблема в регулировании таймаутов, надо делать коннект на неблокируемых сокетах
решение на базе модуля ни есть наилучший вариант по надежности
концепция nginx такова, что модули должны содержать как можно менеьше внешних библиотечных зависимостей (в данном случае OCI, одно из тяжелых решений).
во первых — тяжелеет сам nginx
во вторых — что будет если соединение с Oracle отвалится?
грохнется весь сервер, по умолчанию в ОС время коннекта 60 сек…
При нагрузках — это будет пилипец всему и сразу…
в третьих, тесты тестами, а в реале: логика платежей тяжелее, разве мы строи систему для одного вида входящего запроса?
Как делать постоянный коннект и следить за ним, чтоб не отвалился, я пока не знаю.
Мутить пуул коннекций, сложновато.
Мутить обмен через shm & libevent? а отдельным клиентом общаться с БД и отдавать данные через shm…
честно говоря, я не вдавался в подробности Джаббер протокола
могу ошибаться
но у них разные немного задачи,
XMPP — ориентирован чисто на сообщения, поверх XML
AMQP — бинарный протокол, кроме сообщений возможен обмен файлами и таблицами данных (у меня эти фичи пока не реализованны), ориантирован на широкое вещание — подписка на новости, оповещение о событиях и тд.
>1. Что такое cnn в APMQConection.
вкравшиеся ошибка от copy/paste, fixed
>2. getResult — сомнительная функция. Если все прошло так как и должно было пройти — отлично, смысла вызывать еще метод что бы проверить — как оно там, я не вижу. Если произошла какая-то ошибка, что же, почему бы и не кинуть исключение например
думал над исключением, но иногда нужно иметь результат выполнения операции. В принципе — эта функция надумана. Подумаю над исключением.
> 3. Не нравиться мне вот что — при создании очереди или экченжда у нас появляется режимность, которой нет в соединении.
не совсем понял что такое режимность, но сама идея вопроса понятна
>Надо как-то определиться, или мы делаем инициализацию какого-то инстанса только в конструкторе (тогда по сути у нас не должно быть функций подобных declaere) или же расширенный конструктор у нас является просто методом объединяющим сборку (вот хз как в такое раннее время написать более грамотно) инстанса — тогда добавляем методы connect (в коннекшн), и set* для кучи различных параметров.
А можно пример?
Пусть необходимо опубликовать в незабинденную очередь сообщение:
имеем
$cnn = AMQPConnect();
$ex = new AMQPExchange($cnn, 'php', NO_DECLARE); // объявляем обмен, но не отправляем объявление на сервер, так как по некоторым особенностям обмен был объявлен ранее
$qu = new AMQPQueue($cnn, 'php.xXx', AMQP_NODECLARE ); // не отправлять объявление на сервер, по некоторым особенностям очередь была объявлена ранее
$qu->bind( 'php', 'xXx' ); // привязка очереди и обмена
$ex->publish('xXx вошел в чат', '*') // публикация
функция Declare — это возможность объявления очереди/обмена в соотвествие объектной моделью Протокола. Решил ее реализовать. В принципе объявление — должно проходить автоматически в конструкторе, если не выставлен флаг AMQP_NODECLARE
В соотвествии с Протоколом, есть рекомендация использовать класс BASIC, те вышеприведенный код должен быть таким:
$cnn = AMQPConnect();
$bs = new AMQPBasic($cnn);
$bs->bind( 'php','xXx', 'xXx' ); // привязка очереди и обмена
$bs->publish('php', 'xXx вошел в чат', '*') // публикация
но мне показалось, что предоженный мною вариант удобнее.
>3. И что такое params. Понятно что параметры, а что за параметры. И почему их нельзя менять уже в созданном инстансе какого-либо класса.
Про параметры можно почитать в реализованном АПИ, см ссылку
часть параметров задана по умолчанию.
>Почему к примеру я не могу изменить к примеру таймауты различные или коннект у какой-то очереди или экченжа.
а вот с этим сложнее, но у меня в планах пропатчить класс коннекта на предмет таймаутов. А вот коннект у очереди и эксченджа пока один. Можно еще намутить воды с номерами каналлов, но на практике то вполне и одного канала хватает. Будет потребность — напишем, делов-то всего на часов восемь.
Как вариант возможно открыть два соединения — но зачем???? не вижу практической стороны применения.
>4. метод delete и purge должны совершать действия только с текущими инстансом класса. Если вызываем у какой-то очереди, то изменяется только эта очередь. В другую лезть не надо. Сейчас эта функция очень и очень большой шаг в направлении процедурного программирования.
методы delete и purge решил реализовать в соответствии с Протоколом, пока на практике использую только delete
>5. Где класс сообщения? Судя по phpampglib там имеется куча различных параметров, которые хотелось бы хоть иногда изменять
$res = $exchange->publish( msg, routing_key, [parms]) // задаем параметры и не так их там много. Приоритеты — пока только зарезервированны, но в брокере не реализованны. expiration задается, а также AUTODELETE & DURABLE
но иногда при задачи некоторых нестандартных параметров мы имеем непредсказуемое поведение, например использование флага NOWAIT, по этому лучше сузить возможности и не давать пользователю убивать ситему.
В phpamplib решили объять необъятное и работает криво.
>6. Как насчет какого-нибудь ConnectionManager который бы умел обращаться с кучей различных соединений, которые бы в нем регистрировались при создании, и отложенного соединения, которое реально создается уже при отсылке первого сообщения в какую-либо сторону.
на счет отложенных соединений я думал, — это в ближайших планах
на счет нескольких соединений, думаю должно работать так:
$cnn1 = AMQPConnect('rb1.project.local');
$ex = new AMQPExchange($cnn1, 'php', NO_DECLARE);
$ex->publish('xXx вошел в чат', '*') // публикация
$cnn2 = AMQPConnect('rb2.project.local');
$ex = new AMQPExchange($cnn2, 'mysql', NO_DECLARE);
$ex->publish('xXx вошел в чат', '*') // публикация
имеем по контексту на каждое соединение.
>7. Будет ли очередь поддерживать интерфейс Iterator и как я могу обратиться к сообщениям в очереди?
пока над этим не думал, спасибо за подсказку.
>getItem — это конечно хорошо, но что если мне необходимо получить пятое по счету сообщение, или сразу несколько?
ну пятое по счету не получится — система FIFO, последовательный доступ к каждому сообщению.
возможен вариант — прочитать четыре сообщения с флагом NOASK (не прочитанные), а пятое — как обычное. Четыре сообщения будут висеть в очереди. Это хак. Несколько сразу — циклом.
получить несколько
$arrayOfQueueItems= $queue->consume([n]) — получить массив n-сообщений из очереди (все прочие сбрасываются ) если n не задано — выбираются все сообщения. так как метод consume привязан к очереди, то в целях защиты от зависания: если n>фактического кол-ва сообщений в очереди сделано ограничение, идет опрос состояния очереди.
> Как насчет кучки различных методов, что-то вроде getMessageById? или даже getMessagesByType?
тип пока один plain/text, пока большее не планируется
getMessageById — если честно, то пока и не задумывался что это нужно. Вот приоритеты — нужны бывают;
можно использовать consumer-tag, но как выбирать по нему из очереди не считывая все предыдущие — я не в курсе,
хак: можно все считывать и проверять на id или consumer-tag с флагом NOACK, а потом выполнять удаление конкретных сообщений
вообще брокер ориентирован на FIFO так что танцы с бубнами…
ИМХО
надо делать исключительно «быстрый» поиск иначе отпугнешь всех клиентов
если очень быстро не получается, то удерживай клиента новостями или крутящимся по аяксу прогрессбаром.
но все же надо чтоб поиск был именно быстрым и точным, а не таким как в Яндекс-маркете, когда на заявку «WEB-камера» и мне выдается 10 000 ноутбуцов. у которых есть WEB-камера…
можно придумать систему заявок через RSS или mail, но это уже к поиску отношения не имеет.
но мне лично, например, такая информация не актуальна — если есть возможность ее найти на других сайтах. А, конкуренция сейчас довольно-таки сильная.
если там взять аналогичные настройки:
хотя вполне достаточно 8 воркерах nginx'а и 8 воркерах php-fpm
если там взять аналогичные настройки:
хотя вполне достаточно 8 воркерах nginx'а и 8 воркерах php-fpm
всякое подобное утверждение должно подкрепляться цифрами и фактами
кроме голословных утверждений с статье ничего нет.
я сторонник Unix технологий
>При этом вычисление пароля вторым методом, на моем компьютере, выполнялось значительно быстрее.
желательно такие заявления подтверждать цифрами. что стоит запустить таймер перед вычислениями и остановить после.
И еще посторить 10-100 итераций для усреднения…
Зато наглядно.
я пока ХабраЧайник и что такое для меня малопонятно
но сделаю, как Вы подскажете
PS
про <habracut/> сам узнал из комментариев к первому посту.
я давно думаю над пуулом (MySQL + PHP ), но я не спец по Ораклу и ничего сказать не могу.
из моих исследований по MySQL, хотел сделать демон, который бы раздавал коннекции РНР-вокерам через shmem
но наткнутся на sigfault, для ликвидации которого надо было переписать более 33% кода mysqlclientlib Сизыфов труд.
как вариант — сделать демона, который запускал бы n MySQLClient вокеров, которые постоянно держали бы коннекцию с мускулем, но в этом случае при обмене из PHP, мы клали бы в shmem запрос, оповещали демона и ждали бы оповещения выполнения запроса, после этого брали данные из shm, формировали массив и возвращали в РНР код. т.е. по сути написал бы свою новую либу, а хотелось совместимости.
В общем, история про пул — это на какие грабли мне пришлось наступать и куда копать дальше.
Вам тоже спасибо, давно искал сравнительные характеристики nginx & lighttpd (про lighttpd2.0 узнал из комментов этого блога)
посмотри в сторону использования шаред мемори и libevent
это должно быть быстрее чем fastcgi
(будет время, сам покапаю в эту сторону)
мне тоже нужно будет запускать не легкие процессы…
имел небольшой опыт использования логики модулей, отказался из-за указанных catap причинами.
проблема в регулировании таймаутов, надо делать коннект на неблокируемых сокетах
Кирилл спасибо за развернутый ответ.
решение на базе модуля ни есть наилучший вариант по надежности
концепция nginx такова, что модули должны содержать как можно менеьше внешних библиотечных зависимостей (в данном случае OCI, одно из тяжелых решений).
во первых — тяжелеет сам nginx
во вторых — что будет если соединение с Oracle отвалится?
грохнется весь сервер, по умолчанию в ОС время коннекта 60 сек…
При нагрузках — это будет пилипец всему и сразу…
в третьих, тесты тестами, а в реале: логика платежей тяжелее, разве мы строи систему для одного вида входящего запроса?
Как делать постоянный коннект и следить за ним, чтоб не отвалился, я пока не знаю.
Мутить пуул коннекций, сложновато.
Мутить обмен через shm & libevent? а отдельным клиентом общаться с БД и отдавать данные через shm…
тут есть много над чем подумать.
могу ошибаться
но у них разные немного задачи,
XMPP — ориентирован чисто на сообщения, поверх XML
AMQP — бинарный протокол, кроме сообщений возможен обмен файлами и таблицами данных (у меня эти фичи пока не реализованны), ориантирован на широкое вещание — подписка на новости, оповещение о событиях и тд.
вкравшиеся ошибка от copy/paste, fixed
>2. getResult — сомнительная функция. Если все прошло так как и должно было пройти — отлично, смысла вызывать еще метод что бы проверить — как оно там, я не вижу. Если произошла какая-то ошибка, что же, почему бы и не кинуть исключение например
думал над исключением, но иногда нужно иметь результат выполнения операции. В принципе — эта функция надумана. Подумаю над исключением.
> 3. Не нравиться мне вот что — при создании очереди или экченжда у нас появляется режимность, которой нет в соединении.
не совсем понял что такое режимность, но сама идея вопроса понятна
>Надо как-то определиться, или мы делаем инициализацию какого-то инстанса только в конструкторе (тогда по сути у нас не должно быть функций подобных declaere) или же расширенный конструктор у нас является просто методом объединяющим сборку (вот хз как в такое раннее время написать более грамотно) инстанса — тогда добавляем методы connect (в коннекшн), и set* для кучи различных параметров.
А можно пример?
Пусть необходимо опубликовать в незабинденную очередь сообщение:
имеем
$cnn = AMQPConnect();
$ex = new AMQPExchange($cnn, 'php', NO_DECLARE); // объявляем обмен, но не отправляем объявление на сервер, так как по некоторым особенностям обмен был объявлен ранее
$qu = new AMQPQueue($cnn, 'php.xXx', AMQP_NODECLARE ); // не отправлять объявление на сервер, по некоторым особенностям очередь была объявлена ранее
$qu->bind( 'php', 'xXx' ); // привязка очереди и обмена
$ex->publish('xXx вошел в чат', '*') // публикация
функция Declare — это возможность объявления очереди/обмена в соотвествие объектной моделью Протокола. Решил ее реализовать. В принципе объявление — должно проходить автоматически в конструкторе, если не выставлен флаг AMQP_NODECLARE
В соотвествии с Протоколом, есть рекомендация использовать класс BASIC, те вышеприведенный код должен быть таким:
$cnn = AMQPConnect();
$bs = new AMQPBasic($cnn);
$bs->bind( 'php','xXx', 'xXx' ); // привязка очереди и обмена
$bs->publish('php', 'xXx вошел в чат', '*') // публикация
но мне показалось, что предоженный мною вариант удобнее.
>3. И что такое params. Понятно что параметры, а что за параметры. И почему их нельзя менять уже в созданном инстансе какого-либо класса.
Про параметры можно почитать в реализованном АПИ, см ссылку
часть параметров задана по умолчанию.
>Почему к примеру я не могу изменить к примеру таймауты различные или коннект у какой-то очереди или экченжа.
а вот с этим сложнее, но у меня в планах пропатчить класс коннекта на предмет таймаутов. А вот коннект у очереди и эксченджа пока один. Можно еще намутить воды с номерами каналлов, но на практике то вполне и одного канала хватает. Будет потребность — напишем, делов-то всего на часов восемь.
Как вариант возможно открыть два соединения — но зачем???? не вижу практической стороны применения.
>4. метод delete и purge должны совершать действия только с текущими инстансом класса. Если вызываем у какой-то очереди, то изменяется только эта очередь. В другую лезть не надо. Сейчас эта функция очень и очень большой шаг в направлении процедурного программирования.
методы delete и purge решил реализовать в соответствии с Протоколом, пока на практике использую только delete
>5. Где класс сообщения? Судя по phpampglib там имеется куча различных параметров, которые хотелось бы хоть иногда изменять
$res = $exchange->publish( msg, routing_key, [parms]) // задаем параметры и не так их там много. Приоритеты — пока только зарезервированны, но в брокере не реализованны. expiration задается, а также AUTODELETE & DURABLE
но иногда при задачи некоторых нестандартных параметров мы имеем непредсказуемое поведение, например использование флага NOWAIT, по этому лучше сузить возможности и не давать пользователю убивать ситему.
В phpamplib решили объять необъятное и работает криво.
>6. Как насчет какого-нибудь ConnectionManager который бы умел обращаться с кучей различных соединений, которые бы в нем регистрировались при создании, и отложенного соединения, которое реально создается уже при отсылке первого сообщения в какую-либо сторону.
на счет отложенных соединений я думал, — это в ближайших планах
на счет нескольких соединений, думаю должно работать так:
$cnn1 = AMQPConnect('rb1.project.local');
$ex = new AMQPExchange($cnn1, 'php', NO_DECLARE);
$ex->publish('xXx вошел в чат', '*') // публикация
$cnn2 = AMQPConnect('rb2.project.local');
$ex = new AMQPExchange($cnn2, 'mysql', NO_DECLARE);
$ex->publish('xXx вошел в чат', '*') // публикация
имеем по контексту на каждое соединение.
>7. Будет ли очередь поддерживать интерфейс Iterator и как я могу обратиться к сообщениям в очереди?
пока над этим не думал, спасибо за подсказку.
>getItem — это конечно хорошо, но что если мне необходимо получить пятое по счету сообщение, или сразу несколько?
ну пятое по счету не получится — система FIFO, последовательный доступ к каждому сообщению.
возможен вариант — прочитать четыре сообщения с флагом NOASK (не прочитанные), а пятое — как обычное. Четыре сообщения будут висеть в очереди. Это хак. Несколько сразу — циклом.
получить несколько
$arrayOfQueueItems= $queue->consume([n]) — получить массив n-сообщений из очереди (все прочие сбрасываются ) если n не задано — выбираются все сообщения. так как метод consume привязан к очереди, то в целях защиты от зависания: если n>фактического кол-ва сообщений в очереди сделано ограничение, идет опрос состояния очереди.
> Как насчет кучки различных методов, что-то вроде getMessageById? или даже getMessagesByType?
тип пока один plain/text, пока большее не планируется
getMessageById — если честно, то пока и не задумывался что это нужно. Вот приоритеты — нужны бывают;
можно использовать consumer-tag, но как выбирать по нему из очереди не считывая все предыдущие — я не в курсе,
хак: можно все считывать и проверять на id или consumer-tag с флагом NOACK, а потом выполнять удаление конкретных сообщений
вообще брокер ориентирован на FIFO так что танцы с бубнами…
спасибо за комментарий
надо делать исключительно «быстрый» поиск иначе отпугнешь всех клиентов
если очень быстро не получается, то удерживай клиента новостями или крутящимся по аяксу прогрессбаром.
но все же надо чтоб поиск был именно быстрым и точным, а не таким как в Яндекс-маркете, когда на заявку «WEB-камера» и мне выдается 10 000 ноутбуцов. у которых есть WEB-камера…
можно придумать систему заявок через RSS или mail, но это уже к поиску отношения не имеет.
но мне лично, например, такая информация не актуальна — если есть возможность ее найти на других сайтах. А, конкуренция сейчас довольно-таки сильная.
приятно видеть что на Хабре вспоминают про пхпКлаб
жаль что не хватило кармы проголосовать за статью
сам набивал шишки по ману :)
обращение к топикстартеру — ждем продолжений ;)
модно писать классы, статические методы