AL
Size: a a a
2021 March 22
ЯШ
в том числе
А для чего еще?
ОБ
app thread1 \
app thread2 -- queue - memtx
app thread3 //
iproto /ЯШ
Просто вы же понимаете - что взаимодействие между потоками - совсем не бесплатная штука, и при всей кажущейся выгоде - по факту, с очень высокой вероятностью перф получится сильно хуже?
ОБ
А при работе с данными начнут ещё и блокировки возникать
AL
Просто вы же понимаете - что взаимодействие между потоками - совсем не бесплатная штука, и при всей кажущейся выгоде - по факту, с очень высокой вероятностью перф получится сильно хуже?
оно и так есть
ЯШ
Тогда возникает вопрос: А имеет ли смысл вкладывать в это ресурсы и время, если проблемы понятны, выгода - так себе?
Е
А это ничего, что с данными все равно придется работать в один поток? Вы хотите тяжолую математику в разных потоках обрабатывать?
Да. Именно так
ЯШ
Выгода какая? Вы вместо 100-200-500К рпс - получите удобненький тормоз на 50К максимум, и потом тут будет (как бы это культурно сказать) холивар, что типа а вот там-то типа быстрее, фууууу.
Е
но да, многопоточного доступа к данным в Т не предвидится
Он и не нужен.
AL
Выгода какая? Вы вместо 100-200-500К рпс - получите удобненький тормоз на 50К максимум, и потом тут будет (как бы это культурно сказать) холивар, что типа а вот там-то типа быстрее, фууууу.
я внутренности таранатула не копал - под queue обозначено условное нечто, которое используется сейчас для взаимодействия между сетевым потоком и memtx
ЯШ
я внутренности таранатула не копал - под queue обозначено условное нечто, которое используется сейчас для взаимодействия между сетевым потоком и memtx
Кажется, что бы рассуждать на тему многопоточности - надо копнуть, потому что иначе - это просто флейм, не более
ЯШ
так мы и не спорим
хватило бы сказать, что синхронизация двух очередей в режиме 1читатель-1писатель сильно быстрее, чем синхронизация множества читателей+множества писателей
хватило бы сказать, что синхронизация двух очередей в режиме 1читатель-1писатель сильно быстрее, чем синхронизация множества читателей+множества писателей
Выскажу свое мнение (мнение редакции может отличаться) - то, о чем вы говорите, нужно ИМХО только для создания кастомных коннекторов отличных от IPROTO и HTTP (имеется ввиду httpng, потому что существующий http крутится в основном потоке). Кажется больше оно ни за чем не нужно, т.к. поток работающий сданными один, а их обработка не сильно что бы затратна в большинстве случаев (маршаллинг/анмаршаллинг - в 98% случаев)
ЯШ
Поток, работающий с данными в скоупе бд, один. А речь о потоках, работающих с данными в своей памяти, просто в одном процессе с тарантулом.
Да, но с учетом того, что начиная с версии 2.4 запрещен сендвич, у вас работа с потоком данных ограничена: один раз спросил, один раз получил ответ. Из потока не получится делать ни транзакции, ни многошагового обмена данными.....
ИЕ
я правильно понимаю что речь идет о чем-то типа serviceWorker из браузера ( вычисления / фоновая обработка в изолированной области памяти от страницы браузера)?