оффтоп из «php программист»

[MiksIr]

Не факт. Например в случае чата.

Э... что? Под событийной моделью я понимаю обработку соединений через какой-нибудь epoll, когда ядро дает событие о появлении данных для чтения. Случай чата или случай не чата - тут уже совсем пофиг.

Ну в таком контексте сравнивать не могу, с питоном дела не имел. Но то, что связыку nginx+php+memcached ускорить можно - факт.

Ну сравните в контексте nginx+php vs libevent (phpdaemon) php. Если скрипт у нас делает не много (т.е. не ждет базы и т.п.) - запуск нового скрипта, пусть даже с закешированным опкодом будет ощутимо по сравнению с скриптом в случае phpdaemon. Чисто с точки зрения логики, а уж насколько большой оверхед - не считал, не знаю. Хотя ясно дело, что переписав все на С будет еще быстрее. Но это уже другая тема.

 

[MiksIr]

Что? Потоки не обмениваются данными, они просто имеют доступ к ним.

Угу, а данные - они просто где-то есть. Не в памяти, а предоставлены святым духом. Память процесса, единая память тредов, щаренная память пула процессов... вообще не особо большая разница. А вопрос "как проще" на самом деле вопрос выбора/написания фреймворка, и как результат в итоге - не сильно будет различаться.

 

[MiksIr]

Ну это понятно.
sleep = $db->query('SELECT SLEEP(99999...)')
А так?

А это зависит от того, синхронная ли работа с базой или асинхронная. Синхронность вообще больное место, никто не спорит. Но решается. В mysqli вроде как появилась асинхронная работа с базой.

 

[Absinthe]

MiksIr
1) в случае с асинхроной библиотекой придется переписывать код. Сложность кода возрастет.
2) асинхронные библиотеки не всегда существуют

Угу, а данные - они просто где-то есть.

Да. Ты просто читаешь переменную. Не заботясь об обертках для синхронизации. Лишь изредка ставишь локи и все.

Ну сравните в контексте nginx+php vs libevent (phpdaemon) php. Если скрипт у нас делает не много (т.е. не ждет базы и т.п.) - запуск нового скрипта, пусть даже с закешированным опкодом будет ощутимо по сравнению с скриптом в случае phpdaemon. Чисто с точки зрения логики, а уж насколько большой оверхед - не считал, не знаю.

Мое мнение - оверхед огромный. Особенно если целевое действие примитивное.

 

[MiksIr]

Да. Ты просто читаешь переменную. Не заботясь об обертках для синхронизации. Лишь изредка ставишь локи и все.

Я не понял этой фразы. Локи ака матексы и семафоры и есть синхронизация.

 

[cDLEON]

асинхронные библиотеки не всегда существуют

Для того же phpdaemon автор нахерячил всевозможные асинхронные клиенты для mysql,postgres,mongodb, вопрос только в том - на сколько они стабильны....

 

[Absinthe]

Я не понял этой фразы. Локи ака матексы и семафоры и есть синхронизация.

s/синхронизации/чтения и модификации/

 

[grigori]

кстати, можно же embed-нуть php в nginx
я смотрел как-то - решение несложное, и лучше, чем на php писать веб-сервер полностью

 

[флоппик]

я смотрел как-то - решение несложное, и лучше, чем на php писать веб-сервер полностью

А че его писать, в 5.4 же есть
Готов спорить, кто нибудь на досуге уже подпиливает его в альфа-продакшн вариант )))

 

[grigori]

а разве в 5.4 он может много запросов одновременно держать?

 

[Absinthe]

я смотрел как-то - решение несложное, и лучше, чем на php писать веб-сервер полностью

В книге Шлосснейгла мануал есть, кстати, по внедрению .
Вот только смысл? каждый PHP в любом случае придется держать в отдельном процессе. Разница будет лишь на объем памяти одного воркера апача

 

[MiksIr]

В книге Шлосснейгла мануал есть, кстати, по внедрению .
Вот только смысл? каждый PHP в любом случае придется держать в отдельном процессе. Разница будет лишь на объем памяти одного воркера апача

Это будет как апач с event воркером, который еще экспериментальный. Да и тот дальше обрабатывает в тредах, что может оказаться проблемой для php.

 

[grigori]

нет, я имел ввиду embed-нуть в сам процесс nginx, вместо того чтобы писать свой однопоточный демон на php на libevent

 

[Absinthe]

grigori а в чем профит относительно обычного проксирования? Ну кроме расходов на проксирование?

 

[grigori]

Absinthe в том же, в чем и реализация на phpdaemon - однопоточное решение с одной областью памяти

 

[Absinthe]

Absinthe в том же, в чем и реализация на phpdaemon - однопоточное решение с одной областью памяти

Т.е. ты имел ввиду не полноценный PHP, а нечто с собственным евент-лупом для применения всяких асинхронных db-библиотек и т.д.?
Ну в общем php-вариант ноды?

Я тут подумал, что phpDaemon на самом деле очень производительный. Намного производительное классического решения с апачами или fastcgi. Поэтому заменять его нет смысла - проксировать - и все.

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

 

[alekciy]

Т.е. ты имел ввиду не полноценный PHP, а нечто с собственным евент-лупом для применения всяких асинхронных db-библиотек и т.д.?
Ну в общем php-вариант ноды?

Мне думается, подразумевается, что не будет оверхеда на пересылку данных между процессами ngix <-> php-fpm. Имхо, область задач с асинхронками к бд достаточно узкая.

 

[grigori]

мне кажется, встроить php в nginx - более стабильное решение, чем воевать с libevent и дебажить не слишком развитый phpdaemon,
основной оверхед не в пересылке nginx-fpm, а в инициализации скриптов

 

[Absinthe]

встроить php в nginx - более стабильное решение, чем воевать с libevent

А в чем разница?

а в инициализации скриптов

С евентами ее нет.

 

[grigori]

Absinthe блин, ну если ты не знаешь значение слова embed, что я могу тебе объяснить? посмотри API nginx-а что-ли
разница в том, что обработка соединений и HTTP-протокола в nginx уже реализована лучше, чем в phpdaemon