Spring Boot-இல் performance tuning பெரும்பாலும் database boundary பற்றியது: connection pooling, caching, மற்றும் N+1 query problem-ஐ கொல்வது. முதலில் அளவிடுங்கள் (Micrometer + Actuator metrics), பிறகு மிகப்பெரிய செலவைத் தாக்குங்கள்.
Lazy association-கள் ஒவ்வொரு parent-க்கும் ஒரு query-ஐ வெளியிடுகின்றன, பிறகு ஒவ்வொரு child access-க்கும் மேலும் ஒன்றை:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Association-ஐ ஒரே 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. பெரியது சிறந்தது அல்ல — மிக அதிக 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) அதை ஆதரிக்கவும்.
நீங்கள் optimize செய்வதற்கு முன் diagnose செய்கிறீர்களா என்பதை senior interview-கள் சோதிக்கின்றன. வலிமையான பதில்கள் bottleneck-ஐ நிரூபிக்கும் tool-ஐப் பெயரிடுகின்றன (query-களை எண்ண spring.jpa.show-sql அல்லது datasource-proxy-ஐ enable செய்யுங்கள், Actuator-லிருந்து p99 latency-ஐப் படியுங்கள்), ஒரு அளவுக்கு அதிகமான pool ஏன் தீங்கு விளைவிக்கிறது என்பதை விளக்குகின்றன, மேலும் caching-ஐ வெறும் ஒரு speed knob-ஆக அல்ல, ஒரு correctness problem-ஆக — stale data மற்றும் invalidation — கருதுகின்றன.
விரிவான பதில்களுடன் கூடிய IT நேர்காணல் கேள்விகளின் நூலகம் — Junior முதல் Senior வரை.
நன்கொடை