Настройка производительности в Spring Boot — это в основном про границу с базой данных: connection pooling, кэширование и устранение проблемы N+1. Сначала измеряйте (метрики Micrometer + Actuator), затем атакуйте наибольшую стоимость.
Ленивые ассоциации выдают один запрос на каждого родителя, затем ещё один на каждый доступ к потомку:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Исправьте это, получая ассоциацию одним join:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // один запрос, items загружаются жадно
List<Order> findAllWithItems();
// Или @EntityGraph(attributePaths = "items") на методе репозитория.
HikariCP — пул по умолчанию. Больше — не значит лучше: слишком много соединений перегружают БД. Распространённая формула стартует около cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # под ёмкость БД, а не под число потоков
connection-timeout: 3000 # падать быстро вместо накопления запросов
@Cacheable(value = "products", key = "#id") // отдавать из кэша после первой загрузки
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // инвалидировать при записи
public Product update(Product p) { return repo.save(p); }
Подкрепите это Redis (spring-boot-starter-data-redis) для общего кэша между экземплярами.
Senior-собеседования проверяют, диагностируете ли вы прежде, чем оптимизировать. Сильнейшие ответы называют инструмент, который доказывает узкое место (включите spring.jpa.show-sql или datasource-proxy, чтобы посчитать запросы, читайте p99-latency из Actuator), объясняют, почему завышенный пул вредит, и рассматривают кэширование как проблему корректности — устаревшие данные и инвалидация — а не просто ручку скорости.
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать