📈 ORGUMENTC

Mistakes That Kill Startups (2006)
http://paulgraham.com/startupmistakes.html

да ладно?? он вроде один из самых легких, которые есть

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

при пиковой нагрузке

а exclude?

а так можно? Я даж не знал

Ну мы договорились на увеличение до 6мс

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

но ща уже точно не вспомню - мы уже года два им не пользуем

а какие APM используете?

datadog

только в соседнем чате была та же тема)

так а часто бывает - перепишут, получилось лучше. Но получилось лучше не потому, что другой язык или стек, а потому, что кучу мусора не перенесли из старого проекта. И тогда пишут блог посты как круто переехали с Go на Rust или с Java на Erlang. Проходит годик, и начинают миграцию в другую сторону.
Тут как раз хорошо, что переписали, и увидели что таки нифига были не правы.

В блоге чувак молится на BEAM, но при этом не нашёл тулов для того чтобы сделать тоже самое с JVM. Ну такое..

Зато Staff Software Engineer @ Spotify

вот, кстати, судя по скриншотам, он как раз и пишет на Vert.x, который концептуально и похож на BEAM. так что, это вдвойне удивительно

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

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

Опять таки в копилку - а давай-те заебошим в проект вот это это и это может пригодится