А я думал, что чат штука не тяжелая :)

1:1 не тяжёлая. А группы дорожают экспоненциально с количеством людей в них.

поэтому меня тоже смутили твои "15 в сек" сначала ) в чатах по 10 и по 500 чел это сильно разные результаты

Это суммарно входящих на весь кластер. Кстати, надо посмотреть исходящие, где-то была такая метрика. Завтра уже.

А можешь написать TLDR в чем сложность? У нас в Миро тоже вебсокеты и тоже мы скейлимся от нагрузки, всё работает

Он тут вроде есть в этом чате, можно вспомнить ник и спросить :)

@steve_kite выходи)

Там уже глядишь по больше чек за сервера будет

Miro ванлав ❤️ спасаете меня каждый день. Я смотрел как у вас клиент работает, очень похоже да, protobuf?

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

А так вообщем:
- у нас очень неравномерная нагрузка, на ивент может придти 1000-10000 человек, причем практически одновременно, потусят час-два-три и уйдут.
- в Миро редко бывает(или ошибаюсь?) прям много человек в одной борде, а у нас по 50 человек только в одной комнате, а они еще связаны между собой через спейс, то есть, грубо говоря может быть 10000 чел на одном стейтфул сокете и часть из них тусит в комнатах по 50 чел, каждая комната может слать до 1500/сек месаджей на сервер, что вызывает фанаут в 73500/сек месаджей на участников комнаты. А ведь есть еще "сцены" где сидят до 1000 человек и шлют свои реакции.
- сильно скипать/тротлить нельзя, потому что нужен фреймрейт, ну у вас так же
- когда вынесем стейс в какой нибудь редис - это все равно не конец, потому что там уже надо скейлить хранилище стейта и балансировать нагрузку
- надо еще не забывать про стоимость, если у нас, скажем 10 дней в этом месяце ожидаются эвенты по 10к людей, а в другие дни нагрузка в 2-10 раз меньше - то надо гасить неиспользуемые ресурсы и либо как-то очень быстро их поднимать в ответ на нагрузку, либо синхронизироваться с расписанием эвентов

Хотел спросить, кстати, вы замеряли разницу нагрузки на проц при вашей бинарной сериализации vs json?

Привет
А есть ресурс на котором можно мониторить новые интересные open source проекты?

> Я смотрел как у вас клиент работает, очень похоже да, protobuf?
Вроде не proto, а кастомный бинарный протокол, но сути не меняет, да

> в Миро редко бывает(или ошибаюсь?) прям много человек в одной борде,
Бывает много, но не 10000, это да. Звучит так, что вам надо придумывать как резать спейсы на комнаты 🙂

> вы замеряли разницу нагрузки на проц при вашей бинарной сериализации vs json?
Честно говоря не знаю, этим далековато от меня занимаются. В Яндексе замеряли в поиске и бинарный протокол был сильно быстрее. Но там всё было на жирных тачках по много ядер и рама и на c++, который много умных людей оптимизировали многие годы, поэтому эта разница была заметной. Если с более низкой базы стартовать, то может и не такая разница

а ни у кого часом не отпал слак?
у меня не пингуется и не отдается страница: http://slack.com/

С мегафона норм

Все хорошо

ага, спасибо. пойду копать

Есть такой стартапчик progression. Помогает строить карты развития компетенций.
Загляните в их базу знаний, на основе которой создавалась сама софтина: progression.fyi. Там вы найдете кладезь карт компетенций (не только для продактов) от разных хороших компаний.


https://twitter.com/produnderhood/status/1392028298184638464

ну и даундетектор обычно говорит, если кто-то из популярных сервисов прилег https://downdetector.com/status/slack/

Я у Монзо что-то похожее видел, познавательно: https://monzo.com/blog/lessons-from-implementing-progression-frameworks-at-scale

Редис хорошо кластеризуется, но при переходе с сингл-мастера на кластер появляются нюансы.

Мы в одном узком месте перешли с JSON на CSV )) Нормально сэкономили, прямо вот заметно.

Серверы в чат-кластере между собой тоже на бинарном протоколе разговаривают. С клиентами на JSON.