Привет всем, не подскажите может есть npm клиент через tcp

а не http?

не сталкивался. все известные клиенты через http. на github-е не пробовали искать?

к сожалению все что нашел через http, собственно с чего такой вопрос, предположительно через tcp должен быть больший выхлоп. В чем вопрос, может посдкажете, с ростом числа соединений проседает респонг, проводя бенчмарки вижу что 12 соединений выдают намного лучший результат чем 24, выходит лучше сделать больше запросов на 12 чем меньше но на 24, может подскажете что то?

да, можно попробовать увеличить размер батча. обычно, 100к евентов отправляют за раз. лучше много и редко (один раз на 1-2 секунды)

вы имеете ввиду на запись? я ввел вас в заблуждение, я имел ввиду касательно чтения

это вообще не связано с http / tcp, просто ресурсов CPU не хватает на 24

то есть при вертикали должно расти значительно?

даже 1 запрос может выжрать 100% cpu поэтому 2 одновременных запроса могут работать в 2 раза дольше так КХ устроен, старается выжрать все 100% от всех ресурсов

прикол в том что при идентичных конфигах и ~запросах, 12 соединенией выдают намного больше rps and avg time нежели когда 24 соединения, как это понять? в обоих случаях забит под 100 проц естественно

на каждое соединение создается процесс/io-поток, может это потолок. а потребление памяти смотрели? В CH настроек не так много на параллельное чтение. для движка merge-tree - merge_tree_min_rows_for_concurrent_read

да, памяти процентов 20 максимально выжирает, как поднять потолок, или это уже все

ну а бэнчи на меньшее число соединений проводили? лучше график нарисовать, 1, 5, 10... Вероятно уперлись в бэкенд диска, надо смотреть IO pidstat, iotop

на меньших количествах соединений rps поменьше, так как ботов меньше естественно, и проц просто не грузит на 100 процентов, сама скорость ответа такая же как и на 12, до этого числа все гладко, после - все очень плохо, тестилось на 18(+18)cpu

скорее всего драка за диск. 24 потока мешают друг другу и дергают головы дисков в разные стороны к nvme (ssd) это также относится

>на каждое соединение создается процесс/io-поток, нет, не создается

разделенные пулы потоков все равно есть. и для обработки запроса, и для IO

тогда шард на 2 машини в теории должен это возместить? 24 вместо 12 должны выдать тот же +-avg но rps *2?

нет. EventDriven. Есть пул тредов, по числу cpu. Вне зависимости от кол-ва запросов, 0 , 100 , все едино. Клиентские запросы выполняются в одном или более тредов

да, в теории. На практике есть инициатор, который собирает результат шардов в единый. Но это решаемо, либо умным шардированием, либо использованием реплик вместо шардов.

спасибо за помощь

оно вам зачем? вы через npm читаете миллионы записей в секунду? или пишете? там не такая большая экономия как вам может показаться

вы читаете или пишете? кол-во соединений не влияет влияет кол-во паралельных запросов поделенных на кол-во ядер CPU и кол-во IOPS диска

для CH я понял из ответов ребят, не понял только с чего спор? разве пропускная способность tcp не выше http? как минимум из-за того что они на разных уровнях

накладные расходы на сами протоколы тысячные доли процента разница в формате передаваемых данных через TCP передается Native формат через HTTP тоже можно и Native вставлять или RowBinary разница между парсингом TSV / CSV и Native форматов данных (а не транспортные расходы на протокол) она НЕ ДЕСЯТКИ процентов, и даже не единица и проявляется в основном она на ДЕЙСТВИТЕЛЬНО БОЛЬШИХ объемах - миллионы в секунду... у вас такие объемы? если нет, то вам Native over TCP просто не нужен

спасибо за ответ