Spring Boot'ta performans ayarı çoğunlukla veritabanı sınırıyla ilgilidir: connection pooling, caching ve N+1 sorgu problemini yok etmek. Önce ölçün (Micrometer + Actuator metrikleri), ardından en büyük maliyete saldırın.
Lazy ilişkiler her parent için bir sorgu, ardından her çocuk erişimi için bir sorgu daha yayınlar:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Bunu, ilişkiyi tek bir join'de getirerek düzeltin:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // one query, items eagerly loaded
List<Order> findAllWithItems();
// Or @EntityGraph(attributePaths = "items") on the repository method.
HikariCP varsayılan pool'dur. Daha büyük daha iyi değildir — çok fazla bağlantı DB'yi hırpalar. Yaygın bir formül cores * 2 civarında başlar:
spring:
datasource:
hikari:
maximum-pool-size: 10 # match DB capacity, not thread count
connection-timeout: 3000 # fail fast instead of piling up requests
@Cacheable(value = "products", key = "#id") // serve from cache after first load
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalidate on write
public Product update(Product p) { return repo.save(p); }
Örnekler arasında paylaşılan bir cache için bunu Redis (spring-boot-starter-data-redis) ile destekleyin.
Kıdemli mülakatlar, optimize etmeden önce teşhis edip etmediğinizi test eder. En güçlü yanıtlar, darboğazı kanıtlayan aracı adlandırır (sorguları saymak için spring.jpa.show-sql'i veya datasource-proxy'yi etkinleştirin, Actuator'dan p99 gecikmesini okuyun), aşırı büyük bir pool'un neden zarar verdiğini açıklar ve caching'i yalnızca bir hız düğmesi olarak değil, bir doğruluk problemi olarak — bayat veri ve invalidation — ele alır.
Junior'dan Senior'a detaylı cevaplarla bir BT mülakat soruları kütüphanesi.
Bağış Yap