Комментарии 5
Все замечательно кроме бесполезности этого решения для большинства случаев. Оверхед от инлайн колбэка с yeld-ами на порядок, если не полтора увеличивает время отработки.
Нужно очень постараться, чтобы селект в монго занял столько времени, что потребует асинхронной обертки, например какие-то сложные массовые операции, большие инсерты и т.д. В противном случае больше смысла оборачивать в асинхронку запись в лог (все таки I/O операция :)), чем запрос к mongo.
Нужно очень постараться, чтобы селект в монго занял столько времени, что потребует асинхронной обертки, например какие-то сложные массовые операции, большие инсерты и т.д. В противном случае больше смысла оборачивать в асинхронку запись в лог (все таки I/O операция :)), чем запрос к mongo.
> Все замечательно кроме бесполезности этого решения для большинства случаев. Оверхед от инлайн колбэка с yeld-ами на порядок, если не полтора увеличивает время отработки.
Зато улучшается читаемость кода и скорость разработки, ибо сейчас все сидели бы в asm или c++.
> Нужно очень постараться, чтобы селект в монго занял столько времени, что потребует асинхронной обертки, например какие-то сложные массовые операции, большие инсерты и т.д.
Вы сами ответили на свое предложение, да и глупо использовать синхронные методы в асинхронном фреймворке.
Зато улучшается читаемость кода и скорость разработки, ибо сейчас все сидели бы в asm или c++.
> Нужно очень постараться, чтобы селект в монго занял столько времени, что потребует асинхронной обертки, например какие-то сложные массовые операции, большие инсерты и т.д.
Вы сами ответили на свое предложение, да и глупо использовать синхронные методы в асинхронном фреймворке.
>Зато улучшается читаемость кода и скорость разработки, ибо сейчас все сидели бы в asm или c++.
>да и глупо использовать синхронные методы в асинхронном фреймворке.
Инлайн колбэки дорогие (обычные ощутимо дешевле, но код говно, это да), а люди не от хорошей жизни с нагрузкой соглашаются писать сложную относительно линейки асинхронку.
У нас всегда есть некоторые порции операций ввода-вывода, умещающиеся в один цикл, монго реагирует очень быстро, нет смысла создавать лишний оверхед.
Обращение к монго с архитектурной точки зрения не слишком отличается от обращения к файлу или какому ни будь kvstore, нет смысла городить обертки. Файловый ввод\вывод, вообще лочит работу воркера и… все на это забили, потому что это не важно, никому и в голову не придет делать, например, асинхронный логгер, пишущий в файл.
Могут быть тяжелые запросы к базе данных. Но если обычный пользователь может сделать запрос, который призадуемает монго хотя бы на секунду, то вы будете удивлены тому, как вас повалил один человек, нажимая в браузере f5.
Основная цель существования торнадо — сделать асинхронный сетевой IO. Тупо работу с сокетами.
Надеюсь, что прогнав пару тестов с колбеками и без вы поймете то, о чем я говорю. Если не получится, то почитайте хотя бы то, что пишет сам разработчик торнадо по поводу своего опыта написания асинхронной обертки к MySQL.
>да и глупо использовать синхронные методы в асинхронном фреймворке.
Инлайн колбэки дорогие (обычные ощутимо дешевле, но код говно, это да), а люди не от хорошей жизни с нагрузкой соглашаются писать сложную относительно линейки асинхронку.
У нас всегда есть некоторые порции операций ввода-вывода, умещающиеся в один цикл, монго реагирует очень быстро, нет смысла создавать лишний оверхед.
Обращение к монго с архитектурной точки зрения не слишком отличается от обращения к файлу или какому ни будь kvstore, нет смысла городить обертки. Файловый ввод\вывод, вообще лочит работу воркера и… все на это забили, потому что это не важно, никому и в голову не придет делать, например, асинхронный логгер, пишущий в файл.
Могут быть тяжелые запросы к базе данных. Но если обычный пользователь может сделать запрос, который призадуемает монго хотя бы на секунду, то вы будете удивлены тому, как вас повалил один человек, нажимая в браузере f5.
Основная цель существования торнадо — сделать асинхронный сетевой IO. Тупо работу с сокетами.
Надеюсь, что прогнав пару тестов с колбеками и без вы поймете то, о чем я говорю. Если не получится, то почитайте хотя бы то, что пишет сам разработчик торнадо по поводу своего опыта написания асинхронной обертки к MySQL.
> Инлайн колбэки дорогие
> Надеюсь, что прогнав пару тестов с колбеками и без вы поймете то, о чем я говорю
Прогнал тесты: pastebin.com/6SRADFpr
На моем буке вызов inline callback занимает 0,000007 сек — так что смешно говорить что они дорогие.
Про селект в mongo: в проекте который сейчас разрабатываю база около 2Гб, выборка 20 элементов занимает 4..6мс, если уж экономить то мили-секундами, а не микро-секундами.
Сделал 1000 (в 100 потоков) запросов к проекту: через asyncmongo 9.5 сек, через pymongo 11.5 сек, разница в 2сек.
Я согласен что в данном случае время затрачиваемое на запрос к монго «не существенно», но все же.
У вас есть цифры того что pymongo лучше чем asyncmongo?
> Надеюсь, что прогнав пару тестов с колбеками и без вы поймете то, о чем я говорю
Прогнал тесты: pastebin.com/6SRADFpr
На моем буке вызов inline callback занимает 0,000007 сек — так что смешно говорить что они дорогие.
Про селект в mongo: в проекте который сейчас разрабатываю база около 2Гб, выборка 20 элементов занимает 4..6мс, если уж экономить то мили-секундами, а не микро-секундами.
Сделал 1000 (в 100 потоков) запросов к проекту: через asyncmongo 9.5 сек, через pymongo 11.5 сек, разница в 2сек.
Я согласен что в данном случае время затрачиваемое на запрос к монго «не существенно», но все же.
У вас есть цифры того что pymongo лучше чем asyncmongo?
P.S. Я все это пишу к тому, что пример неудачный, если бы мы делали запрос к стороннему API по http, где ждать явно больше 3-4 ms (столько мы пожертвовали на красоту), то вопросов бы не возникло.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Inline-callback в tornado server для asyncmongo