การจูนประสิทธิภาพใน Spring Boot ส่วนใหญ่เกี่ยวกับขอบเขตของฐานข้อมูล: connection pooling, caching และการกำจัดปัญหา N+1 query วัดผลก่อน (metric ของ Micrometer + Actuator) แล้วจึงจัดการต้นทุนที่ใหญ่ที่สุด
lazy association ยิง query หนึ่งครั้งต่อ parent แล้วยิง เพิ่ม อีกหนึ่งครั้งต่อการเข้าถึง child แต่ละครั้ง:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
แก้ไขด้วยการดึง association มาใน join เดียว:
@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 คือ pool เริ่มต้น ใหญ่กว่า ไม่ได้ ดีกว่า — connection มากเกินไปจะทำให้ 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); }
หนุนหลังด้วย Redis (spring-boot-starter-data-redis) เพื่อให้เป็น cache ที่ใช้ร่วมกันข้ามหลายอินสแตนซ์
การสัมภาษณ์ระดับ senior ทดสอบว่าคุณวินิจฉัยก่อนที่จะ optimize หรือไม่ คำตอบที่ดีที่สุดจะระบุเครื่องมือที่ พิสูจน์ จุดคอขวด (เปิด spring.jpa.show-sql หรือ datasource-proxy เพื่อนับ query, อ่าน p99 latency จาก Actuator), อธิบาย เหตุผล ว่าทำไม pool ที่ใหญ่เกินไปจึงเป็นผลเสีย และมองการ caching เป็นปัญหาเรื่องความถูกต้อง — ข้อมูลเก่าค้างและการ invalidate — ไม่ใช่แค่ปุ่มเร่งความเร็ว
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค