წარმადობის tuning Spring Boot-ში ძირითადად database-ის საზღვართან ხდება: connection pooling, caching და N+1 query პრობლემის მოკვლა. ჯერ გაზომე (Micrometer + Actuator metrics), შემდეგ დაესხი ყველაზე დიდ ხარჯს.
lazy ასოციაციები თითო parent-ზე ერთ query-ს უშვებენ, შემდეგ კი კიდევ ერთს თითო child-ზე წვდომისას:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
გამოასწორე ასოციაციის ერთ 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-სთვის.
senior ინტერვიუები ამოწმებენ, დიაგნოსტიკას აკეთებ თუ არა ოპტიმიზაციამდე. ყველაზე ძლიერი პასუხები ასახელებენ ხელსაწყოს, რომელიც bottleneck-ს ამტკიცებს (ჩართე spring.jpa.show-sql ან datasource-proxy query-ების დასათვლელად, წაიკითხე p99 latency Actuator-იდან), ხსნიან, რატომ აზიანებს ზედმეტად დიდი pool და caching-ს სისწორის პრობლემად აღიქვამენ — მოძველებული მონაცემი და invalidation — და არა უბრალოდ სიჩქარის სახელურად.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა