Мы тут недавно лоадтестили друг дружку перед блек фрайдеем. У меня даунстрим йоба кластер на 1200 тачил на спринге по хз сколько цпу и рам Лоадтестинг проходил через мой сервис (8 инстансов по 0.5 цпу и 2Гб рам каждый), который вызывал тот. С моей стороны ~10 IO вызовов на реквест (включая вот один до даунстрима) и 9 до БД У них примерно столько же, БД та же, только мощнее + паблишат в кафку чот Короче, они встряли на цифре 80к rpm потому что их ноды по ООМ начали уходить потому что их ОРМ генерит слишком много мусора на реквест и он в памяти висит пока хттп запрос не кончится (особенности лайфсайкла выбранного контейнера)

Хм... А почему у них запрос весит на реквесте? У них в реквесте есть ссылки на все запросы?

они так сделали ДЛЯ ОПТИМИЗАЦИИ

они так сделали ДЛЯ ОПТИМИЗАЦИИ

Красивая оптимизация. Хотели какой-то самодельный UoW с трекингом сделать?

у них там типа подключение к БД держит в трекере объектов все объекты с запросами на текущий хттп реквест пока не подиспозится.

Ага. Но там какая-то internal либа, не их творение, но "рекомендованное к использованию"

Точно есть какой-то закон природы про внутренние либы. Типа, чем больше в компании внутренних либ, тем хуже они по качеству

Так это про конкуренцию. В опенсорсе она есть, в компаниях именно "рекомендовано к использованию".

за ланистеров играешь?

@aensidhe спасибо за идею с kvm. Всё установилось, надо только вечерком провода поаккуратнее уложить

Точно есть какой-то закон природы про внутренние либы. Типа, чем больше в компании внутренних либ, тем хуже они по качеству

Но самый адовый пиздец - это когда авторы всего это по-прежнему в строю и считают, что этими библиотеками надо пользоваться и объясняют все что пятьдесят исторических причин почему та или иная ссанина присутствует в самом неожиданном месте (как сейчас помню, что та обёртка вокруг Кафки, которая ее «упростила», при ЛЮБОМ эксепшине комитила текущий офсет и НА ЭТО БЫЛИ ИСТОРИЧЕСКИЕ ПРИЧИНЫ). А причины обычно такие: мы криворуки, но нас не остановить.

Норм тема

Иглиф, мы тебя всё равно узнали.

Да не говори. Больше всего на свете я боюсь прийти в контору и увидеть зависимость от НазваниеКомпнии.Infrastructure.

open Marvel.Arrows

А если фанат ДЦ?

Мол, ничего не делает, а деньги получает

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

у меня есть продюсер который не должен генерить данных в очередь, если она не пуста

Было бы выгодно не строить систему, в которой выгодно геймить систему таким образом

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

Хм, а разве юниттесты пишут в основном не авторы кода?

Дописать никогда не поздно, но выделять это отдельно как чью-то ответственность, имхо неверно.

Это я говорил как способ занять хоть чём-то народ. Как солдаты копают: от забора и до вечера.

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

Это безусловно так, но то что я выше писал это ещё более нездоровая ситуация. Про инфраструктурные пакеты внутри компании.

Имхо, желательно как-то доходить до осознания этого, обсуждать и т.п. Т.е. если есть осознание этого теми, кто способен повлиять на ситуацию, значит надо до всех доводить. Если не довели, и у кого-то руки чешутся внутренние библиотеки для всех писать, то к этому придет.

Здесь требуются некие социальные навыки, чтобы настроить диалог, без этого не обойтись.

Во многих организациях пишут внутренние библиотеки из самых лучших побуждений и от отсутствия опыта злоключений с ними. Да, авторы уверены, что творят добро.

К сожалению вынужден констатировать что немало людей которые пишут внутренние библиотеки, испытывают боль а потом приходят на новое место и опять пишут свои решения

Я помню, как еще во времена C++/MFC начал работать в проекте с обширным фронтом работ ("нет времени на раскачку"). Пришел новый коллега, посмотрел код, спросил: "надо первые недели написать код общего пользования, потом быстрее пойдет." Мне повезло, что я тогда уже застолбил ответственность как архитектор.