щас pagedjs прикручиваю, там есть фишки нужные

ага и придут багрепорты писать )

Ребят, вот вы тут перфоманс либ обсуждаете, а у меня такой вопрос возникает - а именно на ваших масштабах оно вообще будет на что-то влиять?
Ну вот, условно, сериализатор у вас будет в 5 раз медленее. Общее время обработки запроса пусть вырастет на 5мс в худшем случае. Я понимаю, когда вы пилите там что-то масштаба авито или яндекса и 5мс - это полстойки лишней на масштабе, это еще куда ни шло заметно, или вы на серверлессе и лишние 5мс - это шанс вылезти за округление биллинга (и то, надо мерить), но вот так, в обычном то применении, оно вам точно настолько важно?

Ну то есть кажется, что в 90% случаев смотреть надо на все, что угодно, кроме скорости (все равно популярные инструменты не будут фатально медленными, за редким исключением).

Меня просто как девопса несколько удивляют, какие баталии проходят за скорость либ (колличество алокаций памяти и т.д), а потом все это запихивается в продукт, который ходит в базу через полматерика с латенси 10мс на плечо и всем как бы норм:)

Клевый поинт. Я не особо обсуждаю такое, но нам, например, супернерелевантно. Нам даже не особо релевантно то, на каком языке у нас большинстве сервисов написано, потому что мы очень зависим от чужих тулов - платных и опенсорс. Их выполнение занимает около 60% времени

Хз, иначе же скучно 😅

Действительно:)

где? )

Да тут говорят экспресс очень медленный:))

Но вообще это же коммон история такая - выбирать по перфомансу. Чет вот, триггернуло слегка))

Грабли во Вселенной разложены изобретательно. Мы тут писали агрегатор пользовательских событий для рекоммендера. Собрать вместе все просмотры, лайки, шеры, Алишеры, вот это вот всё, и на основе агрегатов строить рекомендации.

Проблема была такая: если нода кластера приложения (ре)стартует, ей надо заново вычитать из Кафки всю историю событий за 15-20 дней. А это несколько десятков миллионов айтемов. Так вот, переход с JSON на CSV дал выигрыш в два раза в скорости подъёма ноды, с 40 минут до 20.

А это, соответственно, происходит каждый деплой сервиса. Так что мы ещё маленько пооптимизировали и добились сокращения процесса до 7 минут, что уже примерно похоже на скорость работы Кафки на отдачу.

Но всё равно грустно, потому что (ре)деплой кластера из трёх нод занимает больше 20 минут, а из четырех - почти полчаса.

Интересная история. Все так.
Вот только кейс из примера входит в 10% ситуаций, когда оно реально влияет (хотя конечно использовать кафку как сторадж это само по себе весьма кхм.. спорное решение, как по мне, я бы из кафки это перекладывал в нечто другое, возможно даже в несколько ином виде с трансформацией и уже оттуда подгружал, но я не знаю условий задачи).

Вообще json и скорость - это такие слова-антогонисты:)

Рекомендательная система, в которой много эвентов - это все таки уже можно назвать хайлоадом. Другое дело что рекомендательные системы на самом деле то мало кто пишет. CRUD же кругом, в основном. С меееленькими точками, где оптимизации реально имеют смысл.

ну есть разница например 100 реквестов в секунду, каждый пусть и с лейтенси, или 1000 реквестов в секунду

В кафку летят входящие события в реальном времени, если их пытаться ещё где-то параллельно хранить - уже будет бутылочное горлышко. Порядок событий не критично, но важен (лайк и отмена лайка, лайк и дизлайк), так что реляционные решения накладывают доп. условия по ключам, не говоря уже об удорожании всего сетапа.

Есть мысль скидывать часовые или суточные пачки на S3 в виде zip-архивов, надо проверять.

На самом деле часто никакой разницы, потому что или у тебя всего 100 реквестов в секунду, или поставить второй сервер дешевле, или у тебя за этим сервисом есть что-то, что скейлится хуже.

ну в реальности то да, в реальности может быть что угодно, не мешай людям задротствовать 🙂