Přepsání serveru v Javě

[balki]

Urobil som to ja. Na ARM32 řádově pomalejší (nepoužitelné) obě. ARM64 oraclí zvládá lépe, ale furt napikaču na rozdíl od amd64. JIT prostě ARM nedává.

No, ale stale moze byt vykon dostatocny, mne to na rpi behalo celkom slusne. Podrobne vykonove testy som nerobil. Pre moje ucely to vsak stacilo, mal som tam servis deploynuty na spring boot.
Oracle  java na ARM daval ovela lepsie vysledky, nez openjdk. Co urobil zboj ma az tak nezaujima. Zaujima ma, ci autor povodneho prispevku skusil oracle javu miesto openjdk. Mozno by mu to usetrilo robotu v prepisovani do brainfucku.

[Reklama]

[Pavel Tišnovský]

Může mi někdo prosím poradit, jakým způsobem přepsat server? Kontext: mám webovou službu, rozhraní je přes JSON, server je napsaný v Javě (přímo nad standardní knihovnou, žádný framework), kód je malý (nějaké základní zpracování dat, IPC k jedné lokální komponentě a přístup do databáze), ale požadavků není málo (tisíce za minutu) a současná verze je dost náročná na paměť a občas se zasekává (asi GC). Koukal jsem na node.js, ale jednovláknovost se mi moc nepozdává (server má ARM64 s 16 vlákny). Mám na přepsání čas a chuť experimentovat, jen si nejsem jistý, jakým směrem se vydat (mám prototyp v čistém C nad syscally, ale nedal bych ruku do ohně za spolehlivost, je to jen proof of concept).

Šlo by pls. ten server pustit s profilerem a získat víc info o tom, kde se to skutečně brzdí? Možná i pustit to s volbou -verbose:gc, ať je vidět, jestli má skutečně problém GC (může být, zrovna ta serializace/deserializace JSONu asi bude dělat mnoho stringů).

[Ondrej Nemecek]

Přesně tak, podle mě je nerozum to přepisovat aniž bych věděl, kde to drhne. Mně se osvědčil JVM Monitor doinstalovaný do Eclipse, kterým jsem se připojil na běžící aplikaci a zjistil, kde aplikace tráví většinu času - v call tree to bylo na pár kliknutí vidět. Použil jsem profilování pomocí samplingu, protože bytecode instrumentace trvala zaprvé hrozně dlouho a zadruhé se s ním aplikace nevyrovnala. Problém byl pak vyřešen asi za hodinu nepatrnou úpravou kódu :-)

Předpokládám, že by tohle šlo udělat po síti i na tom ARMu. Zkoušel jsem i Visual VM, ale nenašel jsem tam tak call tree, bez kterého bych úzké hrdlo asi nenašel (neměl jsem problém v pamětí, ale s rychlostí).

[.]

A ještě k té záměně JVM.
Už podle slov autora vlákna není zjevně problém ve verzi JVM, ale spíš v architektuře aplikace. Pokud na server chodí vyšší desítky požadavků za vteřinu, přičemž každý požadavek = jeden thread, pro zlepšení bude s největší pravděpodobností potřeba přepsat i tu Java aplikaci. Samozřejmě to může drhnout na mnoha místech, nikde se nezmiňuje charakter těch požadavků (sběr dat => zápis nebo spíš čtení).
Takže pokud by se to přepisovalo tak jako tak, je otázka jestli zůstat u Javy velice aktuální, zvláště pak v případě nutnosti učit se třeba nějaký framework.

[Filip Jirsák]

Takže pokud by se to přepisovalo tak jako tak

Upravit aplikaci tak, aby nepoužívala nové vlákno pro každý požadavek, ale aby se používal pool vláken nebo asynchronní IO, přece neznamená přepsat celou aplikaci.

[Reklama]

[zboj]

A ještě k té záměně JVM.
Už podle slov autora vlákna není zjevně problém ve verzi JVM, ale spíš v architektuře aplikace. Pokud na server chodí vyšší desítky požadavků za vteřinu, přičemž každý požadavek = jeden thread, pro zlepšení bude s největší pravděpodobností potřeba přepsat i tu Java aplikaci. Samozřejmě to může drhnout na mnoha místech, nikde se nezmiňuje charakter těch požadavků (sběr dat => zápis nebo spíš čtení).
Takže pokud by se to přepisovalo tak jako tak, je otázka jestli zůstat u Javy velice aktuální, zvláště pak v případě nutnosti učit se třeba nějaký framework.

Než řešit výběr JVM, GC a nevím co ještě, to je fakt lepší to přepsat do něčeho moderního.

[gll]

Než řešit výběr JVM, GC a nevím co ještě, to je fakt lepší to přepsat do něčeho moderního.

Schopní programátoři najdou úzké hrdlo aplikace a to opraví. Lopaty přepisují celou aplikaci do "modernějšího".

[v]

Než řešit výběr JVM, GC a nevím co ještě, to je fakt lepší to přepsat do něčeho moderního.

Schopní programátoři najdou úzké hrdlo aplikace a to opraví. Lopaty přepisují celou aplikaci do "modernějšího".

protože aplikace jsou zásadně obecně dobře navržené a technologie vhodně zvolené

[v]

pro zajímavost, dva miliony a jedno vlákno inkrementují celé číslo:

Kód: [Vybrat]

{-
ghc -threaded -rtsopts threadring.hs
./threadring +RTS -K16M -N1
12.526375s
"..."
1.328629s
1.25943s
1.257285s
-}

import Control.Monad
import Control.Concurrent
import Data.Time

spawn 0 c = return c
spawn i input =  do
output <- newEmptyMVar
forkIO $ forever $
takeMVar input
>>= return . (+1)
>>= putMVar output
spawn (i - 1) output

main = do
t0 <- getCurrentTime
first <- newEmptyMVar
last <- spawn 2000000 first
getCurrentTime >>= print . flip diffUTCTime t0
print "..."
forever $ do
t0' <- getCurrentTime
putMVar first 0
takeMVar last
getCurrentTime >>= print . flip diffUTCTime t0'


[gll]

protože aplikace jsou zásadně obecně dobře navržené a technologie vhodně zvolené

Nevěřím, že by Zboj zvolil vhodnější technologii.

[Filip Jirsák]

Než řešit výběr JVM, GC a nevím co ještě, to je fakt lepší to přepsat do něčeho moderního.

Aha, takže je lepší nejdřív řešit výběr něčeho moderního, pak se naučit něco moderního, přepsat to, a teprve pak řešit výběr VM, GC a nevím co ještě. To se opravdu vyplatí.

Víte, ono to „moderní“ buď bude specializované na tenhle typ úlohy – jenže pak musíte nejprve najít ten správný specializovaný jazyk/nástroj. Pak hrozí, že bude tak úzce specializovaný, že v něm nikdo nic nebude psát a zanikne. Nebo „jenom“ to, že už v něm vy nikdy nenapíšete nic jiného. Nebo prostě jen zůstanete v daném jazyce amatérem. Nebo to „moderní“ bude obecný nástroj, a pak jej zase budete muset nakonfigurovat pro konkrétní použití. Ono totiž vůbec nejde o to, jestli je to „moderní“ nebo „nemoderní“, ale o to, že obecné nástroje jsou prostě obecné, takže je pro konkrétní použití musíte přizpůsobit.

[v]

Ono totiž vůbec nejde o to, jestli je to „moderní“ nebo „nemoderní“, ale o to, že obecné nástroje jsou prostě obecné, takže je pro konkrétní použití musíte přizpůsobit.

čili obecné nástroje byly vytvořeny již dokonalé a nové/lepší nevznikají

[Kamil Podlešák]

Pokud je čas a chuť to přepsat do něčeho jiného a nebude vadit že to má někdo jiný udržovat, tak by byl hřích to nevyužít.
V tomto případě je Go nejlepší volba, protože je to jazyk (resp. "platforma") přesně pro tento účel.

Něco jiného je někde ve firmě, kde se řeší věci jako náklady nebo zastupitelnost. Tam pak platí, že by se mělo zjistit co je přesně špatně a podle toho pokračovat.

[gll]

Ono totiž vůbec nejde o to, jestli je to „moderní“ nebo „nemoderní“, ale o to, že obecné nástroje jsou prostě obecné, takže je pro konkrétní použití musíte přizpůsobit.

čili obecné nástroje byly vytvořeny již dokonalé a nové/lepší nevznikají

Vznikají, ale zrovna zrovna Go není obecný nástroj. Vzniklo pro řešení jednoho konkrétního typu úloh, obecné programování je v tom zbytečně pracné.

[Filip Jirsák]

čili obecné nástroje byly vytvořeny již dokonalé a nové/lepší nevznikají

Nikoli. Ale to, že je něco nového, ještě neznamená, že je to lepší a obecné. Navíc i spousta těch „starých“ nástrojů se pořád vyvíjí, vyvíjí se i způsob práce s nimi.

Aby to někdo špatně nepochopil, já vůbec nejsem proti novým jazykům nebo nástrojům. Pokud někdo má nějaké zadání a rozumí mu natolik, že podle něj napsal program, a teď má čas a chuť to naprogramovat znova, je to ideální příležitost pro vyzkoušení si nového nástroje nebo jazyka (a zároveň trochu past, protože se nejspíš bude pokoušet některé věci řešit stejně, jako by je řešil v tom původním nástroji – opravdový programátor v Cobolu je schopen v Cobolu programovat v jakémkoli jazyce).

Ale mírnil bych to nadšení pro přepis a pro „moderní“ jazyky. Tím, že se něco jenom přepíše, se nic nezíská (kromě nových chyb v kódu). Nic se nezíská ani tím, že se to jen přepíše do „něčeho modernějšího“. Získá se například tím, že se změní architektura – a když už se bude přepisovat architektura, může se jako vedlejší efekt zvolit i jiný jazyk.