Всем привет!

Один из достаточно частых вопросов на собеседованиях - расскажите про стримы в Java, их плюсы и минусы. Если говорить о минусах - всегда под вопрос ставится быстродействие. У меня давно было желание его сравнить, но как часто бывает - меня опередили.
Вот неплохая статья про быстродействие стримов: https://habr.com/ru/articles/807647/

Какие выводы я сделал:

1) тот факт, что на небольшом объеме данных цикл forEach опережает любые виды стримов - ни о чем, им можно пренебречь. Как минимум в 99% случаев. Мне сложно представить кейс, когда объем данных невелик, но нужно выиграть миллисекунды. Скорее всего эти миллисекунды, или даже десятки миллисекунд, мы потеряем на сетевом взаимодействии. У нас же микросервисы, а это значит много сетевых вызовов. Если говорить о причинах - понятно, что на малых объемах данных накладные расходы, которые конечно же есть у стримов, играют роль. И еще момент - чем проще кусок кода, выполняющийся внутри стрима, тем больше отношение накладных расходов стримов к полезному действию.

2) parallelStream в большинстве случаев бьет forEach на больших объёмах данных. Почему так тоже понятно - эффект распараллеливание становится выше, чем накладные расходы на определенном объеме данных.

Итог: стримы можно использовать как вариант по умолчанию, т.к. они улучшают читаемость кода. В высоконагруженных приложениях\ больших объёмах данных имеет смысл смотреть в сторону parallelStream, особенно если есть результаты нагрузочного тестирования. Ну и только на каких-то критичных участках кода, имея на руках результаты НТ, имеет смысл переписать все на циклы

#streams #performance #interview_question

На какие столбцы повесить индексы?

Есть несколько способов это определить.

1) экспертное мнение. Подходит для простых случаев. Ну и ограничение - нужно быть экспертом)

2) спросить условный ChatGPT, скормив ему код. Стильно, модно, молодёжно. Но с текущим уровнем развития LLM видится, что точность не гарантирована)

3) использовать план выполнения запроса, чтобы найти там full scan (seq scan).
Но тут возникает вопрос - на каких запросах его выполнять?
На медленных либо сильно нагружающих СУБД.
Есть несколько вариантов их найти:
а) slow log - отбрасывание наиболее медленных запросов в лог. Что считать медленным - настраивается через граничное время выполнения.
Может быть включён как на уровне Hibernate https://vladmihalcea.com/hibernate-slow-query-log/, так и на уровне базы данных https://www.cybertec-postgresql.com/en/3-ways-to-detect-slow-queries-in-postgresql/ (нужен VPN).
При наличии такой возможности - лучше не уровне БД, например, во время НТ.
Данный способ хорош тем, что прямо указывает на медленные запросы. И этим же плох, т.к. он не покажет массовый запрос, который выполняется быстро, но много.

б) более подробную информацию можно получить с помощью сбора статистики выполнения запросов. Для PostgreSQL это делает модуль pg_stat_statements. Детали тут https://habr.com/ru/articles/488968/
Модуль формирует табличку с данными, в которой можно отсортировать запросы по общему времени выполнения, среднему и максимальному времени, по величине отклонения от среднего, по числу вызовов и даже по нагрузке на процессор и дисковую подсистему.
В общем куча полезной информации, с которой придётся поработать)
Также рекомендую включить его на НТ. А потом измерить влияние включённого модуля на производительность и если оно в районе 1% - включить и на ПРОМе.

P.S. У MySQL аналога pg_stat не нашёл. У Oracle - AWR. У MSSQL - Query Store.

#db #performance