Зачем выкладывать на хабр такие вот, сделанные только под «себя», неконфигурируемые, недопиленные для общего использования вещи?
Какой вообще в этом смысл?
В том-то и дело, что сейчас они объединяют все в единую систему. Убирают понятие пользователя отдельного сервиса. Теперь ты либо юзаешь гугл, либо нет )
Во многом не ценятся вообще никакие дипломы, так как зачастую они ничего не дают и не показывают. Реальный опыт гораздо показательнее и важнее в этом плане. Конечно это не всегда так, но часто.
PHP давно уже может и прекрасно работает для фоновых процессов и демонов, обеспечивая хорошую скорость выполнения. Все это сопутствует серьезным веб проектам и прекрасно укладывается в рамки php.
Распараллеливать же можно очень многие процессы. Сложная обработка изображений, видео, больших объемов текста и многое другое. Эти процессы очень эффективно распараллеливать на одной машине и масштабировать на несколько.
О каком смешении фронтенда и бэкенда вообще идет речь? Причем здесь php-fpm?
Не стоит кичиться знанием «не только php», очень многие здесь знают несколько языков и это не мешает осознанно делать выбор в сторону php.
Там в самом начале написано про эмуляции многопоточности в php, затем описано как именно и с помощью библиотека их эмулирует, какой функционал при этом доступен.
CThread не предоставляет интерфейс для работы с форками, они закопаны далеко внутри и просто используются для асинхронного выполнения задачи. Увы никакой нормальной альтернативы тут форкам я не вижу.
Путанницы при этом на самом деле нет, поскольку нет и настоящей многопоточности в php! Все библиотеки эмулирующие многопоточность так или иначе называют такой асинхронный процесс потоком. Не писать же каждый раз «эмуляция потока» или пул из 16 «эмуляций потока».
Если бы библиотека использовала настоящие потоки, то соответственно и ни слова об эмуляции или форках не было.
Видимо вы не до конца поняли как внутри происходит работа.
На первой конфигурации с одним «потоком» за секунду было выполнено 330 задач. Каждая задача считает эти самые случайные числа. Вначале получает задачу и аргументы из родительского процесса, считает, отдает результат в родительский процесс.
То есть на каждую задачу происходит минимум два обмена данными между процессами. А за секунду в этом случае их случилось 660.
Эта библиотека не является «оберткой вокруг форков». Она эмулирует работу с потоками, потому и называется CThread. Так что для упрощения я называю отдельным потоком совокупность инстанса класса, обеспечивающего эмуляцию работы потока, и форкнутого процесса, не теряющего связи с родительским.
При работе с библиотекой можно вообще не задумаваться о том, что она где-то там использует форки.
P.S.
Вот например более примитивный аналог. Там класс называется еще проще — Thread.
1. Для передачи пакетов-уведомлений используются сокеты. Соответственно при передаче сериализованных данных в сокетах они входят в состав такого пакета и читаются разом. Это особенно эффективно при передаче небольших объемов данных.
В любом случае вы можете протестировать варианты передачи данных и если в вашем случае будет более эффективным какой либо вариант не по умолчанию, то выставить его.
3. В случае одного потока появляются дополнительные накладные расходы (общение между процессами и т.п.), но реального распараллеливания задач не происходит. Мы все равно ждем пока поток завершит одну задачу, чтобы дать ему следующую.
Такая связка, как и другие подобные не подходит. Пришлось бы постоянно в цикле проверять наличие новых сигналов, событий, истечение таймаутов.
LibEvent делает это значительно более эффективно. Коллбэки выполняющие обработку событий дергаются только в нужное время, в остальное не нагружая процессор. В Ubuntu libevent использует для этого системный вызов epoll.
Кстати shmop используется в библиотеке, как один из вариантов передачи данных между процессами. По умолчанию он не задействован, так как оказался не самым эффективным, но его легко можно включить, если в вашей конфигурации он даст прирост производительности:
CThread::$ipcDataMode = CThread::IPC_SHMOP;
Хотя скорее всего в этом случае System V Memory queue (CThread::IPC_SYSV_QUEUE) будет все равно быстрее
P.S.
В состав библиотеки входят удобные врапперы над sysvmsg, sysvsem, sysvshm, shmop и libevent. Возможно кому-то они пригодятся отдельно от CThread.
Это одна из причин, почему переписал NBBC. Принцип работы сохранился, но сам код полностью переписан. Лексер работает похоже на Jevix.
В общем это дало ощутимое увеличение в скорости и позволило сильно усложнить логику обработки.
Я бы парсил как обычно с сохранением обработанной версии и оригинала, но для тех, кто не должен видеть вырезал бы перед отображением.
В действительности просто не использую нигде такой тег ))
Двойная только запись, причем в разные таблицы. Чтение при этом остается быстрым.
Тут все зависит от скорости парсинга. У меня обрабатывается bb-подобный синтаксис. Даже в самом простом варианте все равно быстрее выбирать уже готовые данные чем их парсить каждый раз.
Какой вообще в этом смысл?
Распараллеливать же можно очень многие процессы. Сложная обработка изображений, видео, больших объемов текста и многое другое. Эти процессы очень эффективно распараллеливать на одной машине и масштабировать на несколько.
О каком смешении фронтенда и бэкенда вообще идет речь? Причем здесь php-fpm?
Не стоит кичиться знанием «не только php», очень многие здесь знают несколько языков и это не мешает осознанно делать выбор в сторону php.
Там в самом начале написано про эмуляции многопоточности в php, затем описано как именно и с помощью библиотека их эмулирует, какой функционал при этом доступен.
CThread не предоставляет интерфейс для работы с форками, они закопаны далеко внутри и просто используются для асинхронного выполнения задачи. Увы никакой нормальной альтернативы тут форкам я не вижу.
Путанницы при этом на самом деле нет, поскольку нет и настоящей многопоточности в php! Все библиотеки эмулирующие многопоточность так или иначе называют такой асинхронный процесс потоком. Не писать же каждый раз «эмуляция потока» или пул из 16 «эмуляций потока».
Если бы библиотека использовала настоящие потоки, то соответственно и ни слова об эмуляции или форках не было.
На первой конфигурации с одним «потоком» за секунду было выполнено 330 задач. Каждая задача считает эти самые случайные числа. Вначале получает задачу и аргументы из родительского процесса, считает, отдает результат в родительский процесс.
То есть на каждую задачу происходит минимум два обмена данными между процессами. А за секунду в этом случае их случилось 660.
При работе с библиотекой можно вообще не задумаваться о том, что она где-то там использует форки.
P.S.
Вот например более примитивный аналог. Там класс называется еще проще — Thread.
В любом случае вы можете протестировать варианты передачи данных и если в вашем случае будет более эффективным какой либо вариант не по умолчанию, то выставить его.
2. Парные сокеты и так создаются юниксовыми
3. В случае одного потока появляются дополнительные накладные расходы (общение между процессами и т.п.), но реального распараллеливания задач не происходит. Мы все равно ждем пока поток завершит одну задачу, чтобы дать ему следующую.
4. Все тесты были с использованием APC.
LibEvent делает это значительно более эффективно. Коллбэки выполняющие обработку событий дергаются только в нужное время, в остальное не нагружая процессор. В Ubuntu libevent использует для этого системный вызов epoll.
Кстати shmop используется в библиотеке, как один из вариантов передачи данных между процессами. По умолчанию он не задействован, так как оказался не самым эффективным, но его легко можно включить, если в вашей конфигурации он даст прирост производительности:
Хотя скорее всего в этом случае System V Memory queue (CThread::IPC_SYSV_QUEUE) будет все равно быстрее
P.S.
В состав библиотеки входят удобные врапперы над sysvmsg, sysvsem, sysvshm, shmop и libevent. Возможно кому-то они пригодятся отдельно от CThread.
В общем это дало ощутимое увеличение в скорости и позволило сильно усложнить логику обработки.
Но NBBC мне нравится больше.
В действительности просто не использую нигде такой тег ))
Раньше использовал просто NBBC.
Тут все зависит от скорости парсинга. У меня обрабатывается bb-подобный синтаксис. Даже в самом простом варианте все равно быстрее выбирать уже готовые данные чем их парсить каждый раз.