Podešavanje performansi u Spring Bootu uglavnom se svodi na granicu prema bazi: connection pooling, cachiranje i eliminaciju N+1 problema upita. Prvo mjerite (Micrometer + Actuator metrike), zatim napadnite najveći trošak.
Lazy asocijacije šalju jedan upit po roditelju, a zatim još jedan po pristupu djetetu:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Riješite to dohvaćanjem asocijacije u jednom joinu:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // jedan upit, items eagerly učitani
List<Order> findAllWithItems();
// Ili @EntityGraph(attributePaths = "items") na metodi repozitorija.
HikariCP je zadani pool. Veće nije bolje — previše konekcija zaguši bazu. Uobičajena formula polazi od otprilike cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # uskladi s kapacitetom baze, ne s brojem niti
connection-timeout: 3000 # brzo padni umjesto gomilanja zahtjeva
@Cacheable(value = "products", key = "#id") // posluži iz cachea nakon prvog učitavanja
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalidiraj pri upisu
public Product update(Product p) { return repo.save(p); }
Podržite ga Redisom (spring-boot-starter-data-redis) za zajednički cache među instancama.
Seniorski razgovori testiraju dijagnosticirate li prije nego optimizirate. Najsnažniji odgovori imenuju alat koji dokazuje usko grlo (uključite spring.jpa.show-sql ili datasource-proxy za brojanje upita, čitajte p99 latenciju iz Actuatora), objašnjavaju zašto prevelik pool šteti i tretiraju cachiranje kao problem ispravnosti — zastarjeli podaci i invalidacija — a ne samo gumb za brzinu.
Knjižnica IT pitanja za razgovore za posao s detaljnim odgovorima — od Juniora do Seniora.
Doniraj