Penyetelan performa di Spring Boot sebagian besar berkisar pada batas database: connection pooling, caching, dan mematikan N+1 query problem. Ukur dulu (metrik Micrometer + Actuator), lalu serang biaya yang terbesar.
Asosiasi lazy mengeluarkan satu query per parent, lalu satu lagi per akses child:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Perbaiki dengan mengambil asosiasi dalam satu join:
@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 adalah pool default. Lebih besar bukan berarti lebih baik — terlalu banyak koneksi menyiksa DB. Rumus umum dimulai di sekitar 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); }
Dukung dengan Redis (spring-boot-starter-data-redis) untuk cache yang dibagi lintas instance.
Interview senior menguji apakah Anda mendiagnosis sebelum mengoptimalkan. Jawaban terkuat menyebut tool yang membuktikan bottleneck (aktifkan spring.jpa.show-sql atau datasource-proxy untuk menghitung query, baca latensi p99 dari Actuator), menjelaskan mengapa pool yang terlalu besar merugikan, dan memperlakukan caching sebagai masalah kebenaran (correctness) — data basi dan invalidasi — bukan sekadar tombol kecepatan.
Perpustakaan pertanyaan wawancara IT dengan jawaban mendetail — dari Junior hingga Senior.
Donasi