Spring framework - spomalení kódu

[kvas]

Ahoj, vedeli by ste mi s tymto poradit?

Mam Java kod, ktory riesi nejake heuristiky (praca s kolekciami, porovnavanie, preklapanie objektov z jednej kolekcie do druhej a pod. ziadne diskove/sietove/graficke IO operacie, minimum vypisu do konzole/log suboru) tento kod je 100% nezavisly na Spring frameworku.

Avsak: ked zoberiem tento kod a vlozim jeho volanie do Spring kontrollera (Spring Boot 2.1.2) tak zrazu je cas spracovania cca 2-3x dlhsi, t.j. 2-3sekundy namiesto 1s, ako ked kod spustam mimo Spring, t.j. napr. jUnit alebo plain simple main class.

Podozrieval som Spring, ze tam nieco obaluje pomocou aspektov, tak som  este pre istotu vlozil tu cast kodu do jUnit ale tak, aby sa nastartoval skoro cely Spring kontajner, (t.j. vidim tam vsetky hlasky ako pri starte spring boot, Hibernate, transakcie, security, ... okrem WebApplicationContext, Tomcat a pod.) a zaujimave, ze tu je ten "externy kod" opat rovnako rychly ako bez Springu.

Stretli ste sa s niecim podobnym?

[Reklama]

[Ondrej Nemecek]

Nabízí se obecná a na Springu nezávislá rada - zavolat si na pomoc profiler a běh v obou případech porovnat. Uvidíte, kde program tráví nejvíce času. Z toho se dá usoudit kde je zakopán pes. Jako profiler můžete zkusit třeba Java Mission Control nebo VisualVM.

[kvas]

Vyriesenie (ciastocne).

Nastastie to nebol problem Springu Ked spustim aplikaciu ako "stand-alone" fat spring-boot jar, tak to trva "spravne", t.j. rovnako ako bez Springu. Ked ale aplikaciu spustam v Eclipse, pomocou "Spring Boot App" launcher-a (jedno ci debug alebo run), tak kod je pomaly. Pouzivam Eclipse 2018-12, je mozne, ze tam je nejaky bug.

@Ondrej: Mozem sa na to pozriet, ale odradilo ma od toho to, ze ten kod pouziva vela vnorenych cyklov, v roznych kombinaciach a jednoduche logovanie do konzoly naznacovalo, ze spomalenie nie je specificke pre jedno miesto, ale ze to spomalenie je "rovnomerne roztiahnute", neviem, ci rozumiete co myslim. preto som myslel, ze to bude "nejaka zrada". Ale aj taj zaujimave, preco to ten plugin/launcher tak spomaluje. V jeho nastaveni nie je nic, co by to mohlo sposobovat. Keby to boli tisicky requestov, tam by som chapal, ze sa to nazbiera, ale ako hovorim, ja urobim jeden request a necham javu pocitat a pocitat a nasledne vrati nejaky vysledok.

[Ondrej Nemecek]

Pokud ten launcher nespouští nějaký svůj instrumentační kód (což může běh zpomalit), tak bych stejně radši mrknul, v čem se ty procesy odlišují. Nemusí to být problém launcheru, ale množství přidělené paměti, aktivním typu GC, režimu JVM, verzi VM atd.

Takže bych zkusil kód spustit, zahřát, připojit např. Java Mission Control, kouknout na paměť, využití CPU, čas strávený v metodách, verzi javy atd. a porovnal ho s druhým případem. Můžete tak předejít problémům při běhu v produkčním nasazení, protože tím můžete odhalit slabé místo implementace. Porovnal bych i vytížení samotného hardwaru (využití jader, paměti, IO).

[Filip Jirsák]

Těžko radit, když nevíme, co ten kód dělá. Jestli volá classloader, ServiceLoader, může se tam použít jiná závislost (XML parser, JSE). Rozdíl může být třeba i v tom, že kód spouštíte s jiným nastavením GC nebo prostě spouštíte větší aplikaci, která má větší nároky na paměť – a GC musí paměť během vašeho testu i uvolňovat.

[Reklama]

[kvas]

Můžete tak předejít problémům při běhu v produkčním nasazení, protože tím můžete odhalit slabé místo implementace.

plne suhlasim. urcite na to kuknem nejakym profilerom.

@Filip: kod je uplne primitivna matekatika (+,-,*,/), ale pouzita X tisic/milion-krat spolu s  java kolekciami (mozno problem niekde okolo hashcode/equals), ziadne spominane "pokrocile technologie". Tak ako zvycajne, zrejme bude aj v tomto pripade problem medzi klavesnicou a stolickou:)  - je mozne, ze som nieco prehliadol a s profilerom budem mudrejsi.

dakujem obom za tipy.

[Filip Jirsák]

kod je uplne primitivna matekatika (+,-,*,/), ale pouzita X tisic/milion-krat spolu s  java kolekciami (mozno problem niekde okolo hashcode/equals), ziadne spominane "pokrocile technologie".

Vznikají v tom kódu nové objekty? Třeba i jen kvůli autoboxingu? Podíval bych se na GC, zda nenaráží na limit paměti. Spouštíte to v obou případech stejnou Javou? Nemáte tam při tom spuštění z Eclipse zapnutou nějakou instrumentaci?

Snažil bych se dřív vyloučit jiné vlivy – profilování není nic jednoduchého, a zejména pokud to někde běží rychle a jinde pomalu, je dost možné, že to spuštění pod profilerem ovlivní natolik, že stejně nic nezjistíte.

[kvas]

Vznikají v tom kódu nové objekty?  - ANO, vela
autoboxing - ANO, vela
Spouštíte to v obou případech stejnou Javou? - ANO
... instrumentaci - NIE

Sam som zvedavy, cim to je sposobnene. Ked to zistim, napisem sem dovod.

[Filip Jirsák]

Vznikají v tom kódu nové objekty?  - ANO, vela
autoboxing - ANO, vela
Spouštíte to v obou případech stejnou Javou? - ANO

Na ten GC jste se díval? Normálně bych se jen podíval přes jconsole na graf využití paměti. Podle toho, jak to popisujete, mne jako první věc napadá, že v jednom případě naráží GC na limit paměti a musí uvolňovat objekty, zatímco v druhém případě to dělat nemusí (nebo ne tak často).

Případně bych zvážil vyzkoušet jiný GC, možná budete schopen aplikaci urychlit i proti tomu rychlému běhu.

[kvas]

Zatial som sa este na profiler nepozeral. okrem toho musim riesit opat nieco "s ultra vysokou prioritou"

cenim si ochotu pomoct a dakujem za nu.

[Tomas-T]

Mám podobnou zkušenost z tvorby web aplikací ve Visual Studiu.
Pokud je projekt rozsáhlejší a používé nějaké JS frameworky, tak je spuštěný z VS (v debug režimu) líný.
Po zbuildování a nasazení pak běhá daleko svižněji.
Prostě beru na vědomí, že debugování aplikace má nezanedbatelnou režii.