Как раз такая разбивка и существует - получается после профилирования. Только эта информация используется как раз лишь двумя оптимизациями. В этом плане pgo и go в целом есть куда расти
Спасибо за статью, интересный кейс, приятный текст! Но да, сколько ядер в итоге то нужно для 30k+ rps? И было бы интересно еще узнать, на сколько сервисов в конечном счете этот прием лег: только на ценообразование и оптовых клиентов, или коллеги из других команд переняли опыт и смогли его масштабировать по всей компании, улучшив профит? Или mongo - не всегда целевое решение в компании, а довольно редкое? Вот как будто недосказанность есть легкая по этому кейсу) был бы рад еще рассказам о нечто подобном в вашей практике
Понял! Нет, пока что у разработчиков golang это в беклоге лежит
Как раз такая разбивка и существует - получается после профилирования. Только эта информация используется как раз лишь двумя оптимизациями. В этом плане pgo и go в целом есть куда расти
За статью спасибо! Но как теперь разработчикам работается без кибаны? Удобно ли им юзать кликхаус?
Спасибо за статью, интересный кейс, приятный текст!
Но да, сколько ядер в итоге то нужно для 30k+ rps? И было бы интересно еще узнать, на сколько сервисов в конечном счете этот прием лег: только на ценообразование и оптовых клиентов, или коллеги из других команд переняли опыт и смогли его масштабировать по всей компании, улучшив профит? Или mongo - не всегда целевое решение в компании, а довольно редкое? Вот как будто недосказанность есть легкая по этому кейсу) был бы рад еще рассказам о нечто подобном в вашей практике
Судя по всему, на данный момент pgo только инлайн функций затрагивает