ضبط الأداء في Spring Boot يدور غالبًا حول حدود قاعدة البيانات: تجميع الاتصالات (connection pooling)، والتخزين المؤقت، وقتل مشكلة استعلامات N+1. قِس أولًا (مقاييس Micrometer + Actuator)، ثم هاجم أكبر تكلفة.
الارتباطات الكسولة (lazy) تُصدر استعلامًا لكل أب، ثم استعلامًا إضافيًا لكل وصول إلى ابن:
List<Order> orders = orderRepo.findAll(); // استعلام واحد
(Order o : orders) {
o.getItems().size();
}
أصلحها بجلب الارتباط في join واحد:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // استعلام واحد، تُحمَّل الـ items بشغف
List<Order> findAllWithItems();
// أو @EntityGraph(attributePaths = "items") على دالة الـ repository.
HikariCP هو الـ pool الافتراضي. الأكبر ليس أفضل — فكثرة الاتصالات تُرهق قاعدة البيانات. صيغة شائعة تبدأ قرب cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # طابق سعة قاعدة البيانات، لا عدد الخيوط
connection-timeout: 3000 # افشل بسرعة بدل تكديس الطلبات
@Cacheable(value = "products", key = "#id") // قدّم من الـ cache بعد التحميل الأول
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // أبطِل عند الكتابة
public Product update(Product p) { return repo.save(p); }
ادعمه بـ Redis (spring-boot-starter-data-redis) لـ cache مشترك عبر النسخ.
مقابلات الأقدم تختبر ما إذا كنت تُشخّص قبل أن تُحسّن. أقوى الإجابات تسمّي الأداة التي تُثبت الاختناق (فعّل spring.jpa.show-sql أو datasource-proxy لعدّ الاستعلامات، واقرأ زمن الاستجابة p99 من Actuator)، وتشرح لماذا يضرّ الـ pool المفرط الحجم، وتعامل التخزين المؤقت كمسألة صحة — بيانات قديمة وإبطال — لا مجرد مفتاح سرعة.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع