Panyetelan performa ing Spring Boot umume babagan wates database: connection pooling, caching, lan mateni masalah query N+1. Ukur dhisik (metrik Micrometer + Actuator), banjur serang biaya paling gedhe.
Asosiasi lazy ngetokake siji query per parent, banjur siji maneh per akses anak:
List<Order> orders = orderRepo.findAll(); // 1 query
(Order o : orders) {
o.getItems().size();
}
Benerake kanthi njupuk asosiasi ing siji 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 iku pool default. Luwih gedhe iku dudu luwih apik — kakehan koneksi malah nggebuk DB. Rumus umum diwiwiti cedhak 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); }
Dhukung nganggo Redis (spring-boot-starter-data-redis) kanggo cache sing dienggo bareng ing antarane instansi.
Wawancara senior nguji apa kowe ndiagnosa sadurunge ngoptimalake. Jawaban sing paling kuat nyebut piranti sing mbuktekake bottleneck (aktifake spring.jpa.show-sql utawa datasource-proxy kanggo ngitung query, waca latensi p99 saka Actuator), njlentrehake kenapa pool sing kegedhen ngrusak, lan nganggep caching minangka masalah kebeneran — data lawas lan invalidasi — dudu mung tombol kacepetan.
Pustaka pitakon wawancara IT kanthi jawaban rinci — saka Junior nganti Senior.
Nyumbang