Spring Boot میں performance tuning زیادہ تر database boundary کے بارے میں ہے: connection pooling، caching، اور N+1 query مسئلے کو ختم کرنا۔ پہلے پیمائش کریں (Micrometer + Actuator metrics)، پھر سب سے بڑی قیمت پر حملہ کریں۔
Lazy associations ہر parent کے لیے ایک query چلاتی ہیں، پھر ہر child رسائی پر ایک اور:
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 ہے۔ بڑا ہونا بہتر نہیں — بہت زیادہ connections DB کو تھکا دیتے ہیں۔ ایک عام فارمولا 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) سے پشت پناہی دیں۔
Senior interviews یہ جانچتے ہیں کہ آیا آپ optimize کرنے سے پہلے تشخیص کرتے ہیں۔ مضبوط ترین جوابات وہ tool نام لیتے ہیں جو bottleneck کو ثابت کرتا ہے (spring.jpa.show-sql یا datasource-proxy فعال کر کے queries گنیں، Actuator سے p99 latency پڑھیں)، وضاحت کرتے ہیں کہ ایک بڑا pool کیوں نقصان دہ ہے، اور caching کو صرف رفتار کا بٹن نہیں بلکہ درستگی کا مسئلہ سمجھتے ہیں — stale data اور invalidation۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں