AB
на самом деле, одна из проблем хайлоад капа - это как раз таки гадание на кофейной гуще. решение плохо работает, а почему - только из дебаг вывода небольшого и можно понять. плюс передаваемые из уст в уста знания в чате
Size: a a a
2019 August 27
AB
с другой стороны, количество коннектов тоже мало чего бы сказало, потому что он преконнектит сразу нужное количество соединений
мануально отключаешь keep-alive на ковбое и у тебя rps раза в 3 становится ниже
SS
ну тут же нужно понимать что время создания коннекта примерно равно времени обработки
SS
на большинство запросов
SS
когда тебе там просто нужно значение из памяти готовое взять
SS
поэтому и медленнее, само собой. в одном случае тебе нужно connect на каждый запрос делать, в другом только read/write
AB
я к тому, что это врядли корректный показатель
SS
в реальной жизни может не так сказываться, потому что ты там всякие темплейты рендеришь, запрос проходит через кучу всяких плагинов, модулей, эвентов и прочих абстракций
SS
latency? да, возможно. но за неимением лучшего...
SS
я вот сам думал долго, а что могли взять лучшего такого, принципиально
AB
фронты обычно сами начинают жаловаться, что к беку много запросов и это все заворачивают во что-то другое, снижая рпс от одного клиента.
SS
ну так тут как раз таки рпс немного
SS
там жеж всего сколько, 2к клиентов вроде максимум
SS
мы вообще как-то перескакиваем с темы на тему))
SS
в статье ты тестишь wrk
AB
имхо, далеко это все от реальности
SS
и тут это тоже самое что тестить php и nginx, грубо говоря
AB
за мысли про iolist/iodata спасибо. но чтобы выполнить binary.part нужно все равно это к binary преобразовать. а это копирование как раз
AB
надо дальше думать )
SS
а, то есть тебе нужно объединить сначала несколько бинарей, потом из них взять часть?