Pull to refresh

Comments 19

Это всё понятно, асинхронность и на бейсике можно сделать. Сложность, как мне кажется, в реализации долгоживущего php-процесса. Изначально php был спроектирован под короткий запрос-ответ, эта парадигма позволила отказаться от сложного gc. Теперь же процессы могут работать минимум днями, насколько они подвержены утечкам памяти?

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

Так это тоже не проблема языка. Все те же самые утечки памяти могут быть и на ноде. В long-running процессах управление памятью полностью ложится на плечи разработчика.

Сильное утверждение про long-running процессы и управление памятью, есть мнение что в Java как-то этот вопрос решается без полного прямого управления памятью

так и тут не надо.
сам по себе php в принципе уже давно не течет, вопрос в том не создатите ли вы сами утечки памяти (или фреймворк, который вы используете).
если в java каждый запрос сохранять в памяти и никогда не очищать, то память закончится — тех же самых правил следует придерживаться и в php.
а писать вручную unsetы не нужно (если, конечно, у вас там не какой-то частный случай).

И потом видим OutOfMemoryException в логах )
Если есть GC — это еще не значит что нельзя вызвать утечки.

Утечки можно вызывать всегда, если постараться) Здесь скорее поинт про то, что заявления вида "да это же PHP, у вас просто так память утечет" уже давно не актуальны.

ещё в далёком 2012 году писал автоматические бакенд для чатов и онлайн боёв которые жыли неделями. Без утечек и других каких либо проблем.

Точнее «утечки» были — когда я сохранял ссылки на объекты которые были не нужны уже. Начал удалять ссылки — утечки пропали.

Сейчас стало ещё лучше всё в этом плане.
У нас в продакшене хайлоад API-шки на базе Comet работают месяцами без перезагрузки:

github.com/gotzmann/comet

Вот ничего нового для себя не прочёл.
Но послевкусие от статьи сложное.


Тяжёлый язык для достаточно простой вещи.
То ли текст недостаточно стрктурирован. То ли ещё что-то…
Но тяжело читать было.


Ну и заголовок слегка запутал.

А чем плох вариант просто пробросить системный вызов epoll в линуксе? Linux уже предоставляет возможности асинхронного io виде синхронного вызова epoll_wait в бесконечном цикле. Вот я нашел такую библиотеку (https://github.com/chopins/php-epoll), какие есть недостатки у такого подхода ?


for (;;) {
    $nfds = $epoll->wait($events, MAX_EVENTS, -1);
    if ($nfds == -1) {
        perror("epoll_wait");
        exit(EXIT_FAILURE);
    }

    for ($n = 0; $n < $nfds; ++$n) {
        if ($events[$n]->data->fd == $listen_sock) {
            $conn_sock = stream_socket_accept($stream);
            if (!$conn_sock) {
                perror("accept");
                exit(EXIT_FAILURE);
            }
            stream_set_blocking($conn_sock, false);
            $ev->setEvent(Epoll::EPOLLIN | Epoll::EPOLLET);
            $connFdno = $epoll->getFdno($conn_sock, Epoll::RES_TYPE_NET);
            $ev->setData(['fd' => $connFdno]);
            if ($epoll->ctl(Epoll::EPOLL_CTL_ADD, $connFdno,
                        $ev) == -1) {
                perror("epoll_ctl: conn_sock");
                exit(EXIT_FAILURE);
            }
        } else {
            do_use_fd($events[$n]->data->fd);
        }
    }
}

Понятно что это только работа с голым tcp но ведь можно подключить какую-нибудь библиотеку которая будет парсить из tcp-потока http-запросы и таким образом получим на php асинхронный http-сервер который будет не хуже чем в NodeJS (и также это избавляет от необходимости использовать Apache или Nginx перед php)

Вот и ffi подъехал, думаю пройдёт ещё время и все взлетит, как по мне велосипедостроение у пхпшников в крови)

Подумайте как может быть устроен API подобной библиотеки для парсинга http-запросов. И сравните с уже существующим React\Http\Server.

а чем плох вариант просто вызывать в цикле функцию вроде parseNextHttpRequest(buf) с передачей буфера и получением словаря http-хедеров и значений (а также статуса и тела). Вполне себе органично вписывается в тот пример кода выше где вместо вызова do_use_fd(..) будет вызов parseNextHttpRequest а потом уже обработка самого http-запроса вызовом еще одной функции

единственная концептуальна разница между вашим примером и amphp/reactphp только в том, что у вас epoll, а там select.


мне кажется, никто не запрещает написать свою имплементацию event-loop на этом и использовать в том же самом amphp/reactphp.

хотя в libuv тоже epoll, так что в таком случае разницы нет вообще, кроме того что ffi будет медленее расширения.

Мы у себя решили вопрос проще — для каждой задачи свой инструмент.
Все асинхронные вещи пишем на NodeJS.
UFO just landed and posted this here
многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный"

Покажите мне этих многих. Обычно вижу только нытье забивающих гвозди микроскопом или делающих троллейбус из булки хлеба.

Sign up to leave a comment.

Articles