Spring Boot में performance tuning ज़्यादातर database boundary के बारे में है: connection pooling, caching, और N+1 query समस्या को खत्म करना। पहले माप करें (Micrometer + Actuator metrics), फिर सबसे बड़ी लागत पर हमला करें।
Lazy associations प्रति parent एक query issue करती हैं, फिर प्रति child access एक और:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
इसे एक ही join में association fetch करके ठीक करें:
@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 default pool है। बड़ा होना बेहतर नहीं है — बहुत अधिक connections DB को थका देते हैं। एक आम formula 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); }
Instances के आर-पार साझा cache के लिए इसे Redis (spring-boot-starter-data-redis) से back करें।
Senior interviews जाँचते हैं कि क्या आप optimize करने से पहले diagnose करते हैं। सबसे मज़बूत उत्तर वह tool नाम लेते हैं जो bottleneck को साबित करता है (queries गिनने के लिए spring.jpa.show-sql या datasource-proxy सक्षम करें, Actuator से p99 latency पढ़ें), समझाते हैं कि एक बड़ा pool क्यों नुकसान करता है, और caching को केवल एक speed knob नहीं बल्कि एक correctness समस्या — बासी data और invalidation — के रूप में मानते हैं।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें