Penalaan prestasi dalam Spring Boot kebanyakannya tentang sempadan pangkalan data: connection pooling, caching, dan membunuh masalah pertanyaan N+1. Ukur dahulu (metrik Micrometer + Actuator), kemudian serang kos yang paling besar.
Perkaitan lazy mengeluarkan satu pertanyaan setiap induk, kemudian satu lagi setiap akses anak:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Betulkannya dengan mengambil perkaitan itu dalam satu join tunggal:
@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 ialah pool lalai. Lebih besar bukan lebih baik — terlalu banyak sambungan mencambah DB. Formula lazim bermula berhampiran cores * 2:
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); }
Sokongnya dengan Redis (spring-boot-starter-data-redis) untuk cache yang dikongsi merentas instance.
Temu duga peringkat kanan menguji sama ada anda mendiagnosis sebelum anda mengoptimum. Jawapan yang paling kuat menamakan alat yang membuktikan halangan (aktifkan spring.jpa.show-sql atau datasource-proxy untuk mengira pertanyaan, baca latensi p99 daripada Actuator), menerangkan mengapa pool yang terlalu besar mencederakan, dan menganggap caching sebagai masalah ketepatan — data basi dan invalidasi — bukan sekadar tombol kelajuan.
Pustaka soalan temu duga IT dengan jawapan terperinci — daripada Junior hingga Senior.
Derma