Το performance tuning στο Spring Boot αφορά κυρίως το όριο της βάσης δεδομένων: connection pooling, caching και εξολόθρευση του προβλήματος N+1 query. Μέτρα πρώτα (μετρικές Micrometer + Actuator), και μετά επιτέθηκε στο μεγαλύτερο κόστος.
Τα lazy associations εκδίδουν ένα 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. Το μεγαλύτερο δεν είναι καλύτερο — πολλές συνδέσεις καταπονούν τη 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 σε όλα τα instances.
Οι senior συνεντεύξεις ελέγχουν αν διαγιγνώσκεις πριν βελτιστοποιήσεις. Οι ισχυρότερες απαντήσεις ονομάζουν το εργαλείο που αποδεικνύει το bottleneck (ενεργοποίησε spring.jpa.show-sql ή datasource-proxy για να μετρήσεις queries, διάβασε το p99 latency από το Actuator), εξηγούν γιατί ένα υπερμεγέθες pool βλάπτει, και αντιμετωπίζουν το caching ως πρόβλημα ορθότητας — παλιά δεδομένα και invalidation — όχι απλώς ως διακόπτη ταχύτητας.
Μια βιβλιοθήκη ερωτήσεων συνέντευξης IT με αναλυτικές απαντήσεις — από Junior έως Senior.
Δωρεά