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