Spring Boot ਵਿੱਚ performance tuning ਜ਼ਿਆਦਾਤਰ database boundary ਬਾਰੇ ਹੈ: connection pooling, caching, ਅਤੇ N+1 query problem ਨੂੰ ਖ਼ਤਮ ਕਰਨਾ। ਪਹਿਲਾਂ measure ਕਰੋ (Micrometer + Actuator metrics), ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੀ ਕੀਮਤ 'ਤੇ ਹਮਲਾ ਕਰੋ।
Lazy associations ਹਰ parent ਲਈ ਇੱਕ query, ਫਿਰ ਹਰ child access ਲਈ ਇੱਕ ਹੋਰ ਭੇਜਦੀਆਂ ਹਨ:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
ਇਸਨੂੰ association ਨੂੰ ਇੱਕ single join ਵਿੱਚ 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 ਨੂੰ thrash ਕਰਦੇ ਹਨ। ਇੱਕ ਆਮ 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 enable ਕਰੋ, Actuator ਤੋਂ p99 latency ਪੜ੍ਹੋ), ਸਮਝਾਉਂਦੇ ਹਨ ਕਿ ਇੱਕ oversized pool ਕਿਉਂ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ caching ਨੂੰ ਇੱਕ correctness ਸਮੱਸਿਆ ਵਜੋਂ ਮੰਨਦੇ ਹਨ — stale data ਅਤੇ invalidation — ਸਿਰਫ਼ ਇੱਕ speed knob ਨਹੀਂ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ