Анализ производительности ORM-систем

Нельзя честно объявить одну ORM “быстрее” без workload. Часто bottleneck определяют SQL plan, число round trips, объём результата, connection pool и mapping, а не название ORM.

Что измерять

request latency
├── ожидание connection pool
├── network round trips
├── выполнение SQL
├── чтение result set
├── materialization entities
├── dirty checking / flush
└── serialization

Собираю:

• p50/p95/p99 latency, а не только average;
• число SQL на business operation;
• rows read/returned;
• DB execution plan и buffers;
• pool wait/active connections;
• heap allocation и GC;
• warmup и одинаковый dataset.

Воспроизводимый эксперимент

1. Зафиксировать schema, индексы, dataset и версию DB.
2. Описать запрос и transaction boundary.
3. Прогреть JVM/connection pool.
4. Отделить cold cache от warm cache.
5. Повторить измерения и сохранить distribution.
6. Менять один фактор за раз.

Microbenchmark in-memory mapping не отвечает на вопрос о production endpoint. Для Java CPU-кода подходит JMH, для SQL — план и workload на отдельном стенде; end-to-end измеряется как операция системы.

Частые причины

N+1

Сначала читается список parents, затем lazy query на каждого. Считаю SQL, использую join fetch, EntityGraph, batch fetch или отдельную projection по смыслу. Один гигантский join тоже может дать cartesian explosion. См. Проблема N plus 1 Select Hibernate, Кейс N plus 1 при обходе иерархии.

Слишком широкий граф

Entity загружает columns/associations, которые response не использует. Projection уменьшает data transfer и materialization.

Большой persistence context

Batch обновляет тысячи managed objects, dirty checking и memory растут. Помогают JDBC batch, chunk, периодические flush/clear и bulk DML — с учётом обхода entity lifecycle.

Неверный индекс

ORM не компенсирует table scan. Проверяю реальный SQL и execution plan с фактическими значениями/статистикой.

Кэш

First-level cache относится к Session. Second-level/query cache имеет invalidation и consistency cost. Hit rate без проверки stale data и memory ничего не доказывает. Сначала устраняю неправильный access pattern.

Типичные сбои

• Сравнивать libraries на разных SQL/schema.
• Измерять только один быстрый запуск без JVM warmup.
• Включить подробный SQL log и считать его overhead производительностью ORM.
• Исправить N+1 огромным join и получить множество повторяющихся строк.
• Увеличить pool выше capacity БД.
• Оптимизировать mapping, когда 95% времени занимает lock wait.

Вопросы для собеседования

Что измерить первым при медленном ORM endpoint? End-to-end latency и число/время реальных SQL запросов.

Почему среднее время недостаточно? Оно скрывает tail latency и редкие блокировки.

Всегда ли join fetch исправляет N+1? Нет, он может раздуть result set; strategy зависит от cardinality и нужной projection.

Почему большой pool может замедлить систему? Создаёт больше конкурирующих запросов, locks и очередей внутри БД.

Что делает first-level cache? Хранит identity managed entities в одном persistence context, а не ускоряет все requests приложения.

См. Hibernate, Entity Graph, Проблема декартова произведения Cartesian product problem в Hibernate.