Меню
Что нового?

HTTP/2

  • Автор темы Автор темы grigori
  • Дата начала Дата начала
флоппик, прости, но с чем связана твоя последняя фраза и что она означает?
реализация других протоколов не значит, что реализация асинхронной работы с mysql через нативный драйвер невозможна или неэффективна,
там может быть фатальный изъян
 
Последнее редактирование:
MiksIr написал(а):
А как иначе мультиплекс писать? По сути в мультиплексе должен быть один ожидающий цикл, в котором и активность входящих соединений и ожидание ответа базы.
Нажмите для раскрытия...
иначе чем что? господа, не могли бы вы писать логически связанные фразы?

асинхронность именно так и пишется - ожидается активность входящих соединений и ответы базы.
в чем вопрос-то?
 
В том, можно ли в списки mysqli_poll запихнуть ресурсы созданные socket_create/socket_accept что бы принимать соединения и работать с сокетами.
 
grigori написал(а):
флоппик, прости, но с чем связана твоя последняя фраза и что она означает?
реализация других протоколов не значит, что реализация асинхронной работы с mysql через нативный драйвер невозможна или неэффективна,
там может быть фатальный изъян
Нажмите для раскрытия...
Фатальный изьян там, видимо, в невозможности использовать mysqli ресурсы вместе с libevent? Это вопрос если что, сам не пробовал.
 
mysqli сам по себе в цикл не входит и не блокирует, с ним можно работать из цикла либивента

MiksIr написал(а):
В том, можно ли в списки mysqli_poll запихнуть ресурсы созданные socket_create/socket_accept что бы принимать соединения и работать с сокетами.
Нажмите для раскрытия...
а зачем работать с сокетами из mysqli_poll?
 
Да, но для этого нужно как-то добраться до tcp сокета, коим ресурс mysqli не является. Это и может быть проблемой. А может просто этот код появился раньше чем асинхронность в mysqli...
 
можно вынести mysql_poll в соседний поток, запускать mysql_poll с таймаутом 1 мс, дергать reap_async_query() не дожидаясь poll()
я бы сделал как угодно, но без парсинга протокола mysql на php

главная проблема этой архитектуры - затык в одно ядро проца, главный цикл должен быть как можно легче, чем он тяжелее - тем быстрее ляжет под нагрузкой,
но нет, они его еще обработкой бинарного протокола нагружают
 
Парсинг бинарных данных как раз не должен быть затратный. А ты предлагаешь как раз нагружать процессор постоянным вываливанием из poll-а и проверкой -а не поставил ли соседний поток задач на работу с базой. А соседний поток по работе с сетью тоже придется постоянно просыпать - что бы он проверял - нет ли ответных данных от базы. И это при том, что специально создан механизм переноса этого ожидания данных в ядро.
Затык то на ядро легко решается несколькими воркерами. Во многих случаях даже IPC между воркерами не нужен.
 
В случае с mysql есть как минимум libdrizzle, совместимая по протоколу с libmysql и умеющая работать асинхронно и встраиваться в event loop - вот, скажем, пример с libev. Впрочем, большинство протоколов недостаточно сложны, чтобы было затруднительно их реализовать в рамках event loop based-фреймворка - вон и в node.js, и в reactphp все сделано уже. Другое дело, что есть более удобные средства разработки, чем js/v8 и php/zend, - когда event loop скрыт внутри и не надо устраивать ад колбэков и нет проблем с обработкой ошибок, - но и на js и php это в принципе решается специализированными фреймворками.

Вообще большинство сетевых приложений io-bound, а вовсе не cpu-bound. С масштабированием по ядрам для веб-приложения обычно вообще не проблема - количество запросов, обрабатываемых за среднее время обработки одного запроса, значительно превышает количество ядер, так что прекрасно работает классическая схема master + workers. Если очень нужен IPC между воркерами - это решается классическими unix ipc средствами, при желании можно сделать и тредпул.
 
Последнее редактирование:
если он относительно незатратный - да, а ipc в виде сокетов тут не избежать
 
А для cpu bound задач сразу уместно говорить о масштабировании вычислений не только по ядрам, но и по серверам, а тут мы приходим к map-reduce как ни крути ;)
 
мне кажется, расстояние между single-core и map-reduce довольно велико
а вообще, php для всего этого неудобен
 
А мне кажется не так уж велико. Если мы можем разделить задачу на отдельные сервисы, обменивающиеся данными, то в общем-то все равно, это пачка одноядерных машинок или пачка ядер. (Понятно, что на одной машинке можно избежать копирования данных, но это мелочи при cpu-bound). А если сама по себе неделимая задача уже не помещается в ядро - тут остается два варианта, либо мы можем выразить ее в терминах map-reduce и сделать таким образом делимой, либо все, приехали.
 
можно реализовать как соседний процесс, а не поток, и получить сервисную архитектуру, и дальше по тексту :)
 
grigori написал(а):
можно реализовать как соседний процесс, а не поток, и получить сервисную архитектуру, и дальше по тексту :)
Нажмите для раскрытия...
А IPC процессов сделаем на сокетах, и процессу работающему с базой придется слушать сокеты, и опять мы на том же месте.
 
ну, да, при cpu bound нет никакого смысла разводить всю эту асинхронщину. Это вроде очевидно :)
 
Войдите или зарегистрируйтесь для ответа.
Сверху