Недавно у меня появилась задача по снижению аллокации в очень горячем месте кода. Там происходит тривиальное: запускаются Task'и в которых заранее известным набором handler'ов обрабатываются объекты. Вооружившись профайлером, я с удивлением обнаружил, что много памяти (и много времени GC) затрачивается на удаление объектов-замыканий.

https://habr.com/ru/post/677818/?utm_source=habrahabr&utm_medium=rss&utm_campaign=677818

Method Dispatch или чего не мы не замечаем при работе программы?

https://habr.com/ru/post/673400/?utm_source=habrahabr&utm_medium=rss&utm_campaign=673400

В современной веб разработке сложно переоценить значение такого инструмента как кэш. Мы сохраняем результаты выполнения длительных, дорогостоящих или часто выполняемых операций в некое хранилище, обратиться к которому будет быстрее и дешевле чем к первоисточнику или дешевле чем повторять операцию. В качестве такого хранилища обычно выступает оперативная память или же оптимизированные для быстрого доступа по ключу базы данных, такие как Redis. Кэш это незаменимый инструмент для уменьшения времени отклика и повышения масштабируемости приложения. Однако он имеет свои ограничения, которые связаны в основном с размером кэша. У нас не хватит оперативной памяти и пространства в Redis чтобы полностью закешировать таблицу базы данных с миллионами записей. Для решения проблемы использования кэша при большом объеме исходных данных и ограниченных ресурсах, мы должны применить некий алгоритм, который позволит нам кешировать только самое необходимое - часто запрашиваемые элементы. В этой статье мы детально рассмотрим применение одного из таких алгоритмов кэширования - LRU в контексте ASP NET Core приложения.

Эта статья может быть полезна разработчикам, которые ищут пути повышения производительности веб приложения, а также всем разработчикам, заинтересованным в расширении своего профессионального инструментария.

https://habr.com/ru/post/673224/?utm_source=habrahabr&utm_medium=rss&utm_campaign=673224

«Гарри Поттер и философский камень», (2001)

ИТ-шником (программистом) нынче быть привлекательно. Дата саентистом тоже неплохо. Создаются и множатся курсы. Только вот они все однобокие. Несмотря на большое количество языков, большое количество технологий и алгоритмов, несмотря на весь накопленный в ИТ области багаж, 99% датасаенс курсов строятся по пути python-pandas.

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

Вся аргументация «за питон» строится исключительно по принципу «не думать», «рука рынка, «ну у нас же уже есть в проде 10 строк кода на питоне, что же делать?». Хотя элементарные технологические тесты и оценка экономической эффективности частенько дают неопровержимые доказательства, что DS питон является безответным поглотителем доли ИТ бюджета компаний. Взглянем ниже более пристально на отдельные моменты.

Все предыдущие публикации.

https://habr.com/ru/post/670250/?utm_source=habrahabr&utm_medium=rss&utm_campaign=670250

Привет! Меня зовут Александра, я работаю в отделе тестирования производительности Тинькофф. Мы продолжаем наш цикл статей, посвященных работе Gatling с различными протоколами. Ранее мы уже рассмотрели работу с HTTP, JDBC и gRPC. В этой статье поговорим о работе Gatling с Kafka.

https://habr.com/ru/post/666886/?utm_source=habrahabr&utm_medium=rss&utm_campaign=666886

Как можно перевыполнить KPI и, тем не менее, уйти в минус, а затем поменять схему работы и выйти в плюс для обеих сторон? Рассказываем на примере сотрудничества агентства Adsbalance с разработчиком игр Goat Games.

https://habr.com/ru/post/664868/?utm_source=habrahabr&utm_medium=rss&utm_campaign=664868

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

В этой статье мы рассмотрим NBomber как легкую для освоения альтернативу JMeter, а также постараемся ответить на вопрос "Почему я должен проводить нагрузочное тестирование именно с NBomber ?".

Эта статья предназначена для .NET разработчиков, которые хотят пополнить свой инструментарий удобным инструментом для нагрузочного тестирования, а также тем кто рассматривает альтернативы JMeter для экосистемы .NET.

https://habr.com/ru/post/664824/?utm_source=habrahabr&utm_medium=rss&utm_campaign=664824

Всем привет! Команда тестирования производительности Тинькофф продолжает цикл статей о нагрузочном тестировании различных протоколов с помощью Gatling.

В прошлой статье мы показали, как протестировать JDBC-протокол с помощью Gatling. В этой — разберем протокол gRPC.

https://habr.com/ru/post/664674/?utm_source=habrahabr&utm_medium=rss&utm_campaign=664674

Цель этой статьи — изучить известные факты о грядущем расширении модели многопоточности Java.

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

Да, мы говорим о JEP-425: Virtual Threads.

https://habr.com/ru/post/663570/?utm_source=habrahabr&utm_medium=rss&utm_campaign=663570

Привет! Меня зовут Александра, я работаю в отделе тестирования производительности Тинькофф. Этот текст — часть цикла статей, посвященных тестированию производительности с помощью инструмента Gatling. В предыдущей статье мы с командой рассказали о работе Gatling с HTTP. Еще мы написали вводную статью, из которой можно узнать, что такое Gatling и как мы его используем. В этой статье мы поговорим о работе Gatling с протоколом JDBC.

https://habr.com/ru/post/663718/?utm_source=habrahabr&utm_medium=rss&utm_campaign=663718