Přepsání serveru v Javě

[gll]

Jestli všechny požadavky přistupují ke stejné databázi, tak s největší pravděpodobností nestíhá databáze.

[Reklama]

[Mirek Prýmek]

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

Pokud je hlavní problém v tom, že se pro každý req spouští samostatné vlákno (a zároveň se OP chce zbavit Javy), tak by Erlang rozhodně pomohl. Dál v něm může každý req zpracovávat ve vlastním procesu a přitom se mu to krásně bude samo škálovat přes všechna dostupná jádra - žádný pool tam není potřeba, bude to fungovat samo, zabezpečí to erlangovský scheduler.

[gll]

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

Pokud je hlavní problém v tom, že se pro každý req spouští samostatné vlákno (a zároveň se OP chce zbavit Javy), tak by Erlang rozhodně pomohl. Dál v něm může každý req zpracovávat ve vlastním procesu a přitom se mu to krásně bude samo škálovat přes všechna dostupná jádra - žádný pool tam není potřeba, bude to fungovat samo, zabezpečí to erlangovský scheduler.

Pokud ty procesy přistupují k nějakým omezeným prostředkům, nebo žerou hodně paměti, tak jich chcete mít jen omezený počet.

[Filip Jirsák]

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

tak by Erlang rozhodně pomohl

Podstatné bylo to „pokud ta vlákna skutečně něco dělají“. Pokud je ten server přetížený tím, že má moc práce, nepomůže to, že budete práci jiným způsobem přerozdělovat. Tam je řešením jedině řadit požadavky do fronty a nepřijímat další požadavky, pokud je fronta moc dlouhá.

Přerozdělení pomůže jedině tehdy pokud ta vlákna ve skutečnosti nic moc nedělají a většinu času tráví čekáním. Pak může pomoci koncepce procesů použitá v Erlangu, a nebo třeba asynchronní zpracování v Javě – když se vlákno dostane do bodu, kde má na něco čekat, vlákno se uvolní a začne zpracovávat něco jiného. A teprve když je ten požadavek, který způsobil čekání, vyřízen, nějaké vlákno dostane ke zpracování odpověď.

[Mirek Prýmek]

Pokud ty procesy přistupují k nějakým omezeným prostředkům, nebo žerou hodně paměti, tak jich chcete mít jen omezený počet.

Ano - a přesně proto, pokud se týče CPU, spouští Erlangovský scheduler tolik OS-vláken, kolik je jader Není to závislé na počtu (erlangovských) procesů.

Pokud je problém s pamětí nebo GC, tak ten u Erlangu taky s velkou pravděpodobností nebude, protože v Erlangu je GC lehčí než v Javě.

Pokud je problém s DB, tak se i v Erlangu musí použít pool, tam nijak nepomůže.

Jedině pokud by aplikace dělala nějaké intenzivní výpočty, tak by byl Erlang vyloženě nevhodná volba.

Podstatné bylo to „pokud ta vlákna skutečně něco dělají“. Pokud je ten server přetížený tím, že má moc práce,

...tak nepomůže nic než optimalizovat kód nebo povýšit hw, protože Java je slušně výkonná a přepsáním do jiného jazyka se moc nezíská.

nepomůže to, že budete práci jiným způsobem přerozdělovat.  Tam je řešením jedině řadit požadavky do fronty [...]

Netvrdil jsem, že pomůže přerozdělení, ale že v Erlangu člověk může dál psát tím pohodlným způsobem, že každý request řeší v samostatném "vláknu" (erlangovském procesu) a scheduler za něj rozprostření po dostupných CPU vyřeší (pro dobře napsaný kód velmi optimálně) sám. Čili má člověk optimalitu poolu zadarmo, aniž by nějaký pool, fronty, zamykání atd. musel řešit.

[Reklama]

[Filip Jirsák]

Čili má člověk optimalitu poolu zadarmo, aniž by nějaký pool, fronty, zamykání atd. musel řešit.

To samé platí i při použití vhodných frameworků nebo knihoven.

[b.]

Pokud máte čas na trochu experimentování, neváhal bych zkusit Elixir + http://www.phoenixframework.org/

[gll]

Pokud ty procesy přistupují k nějakým omezeným prostředkům, nebo žerou hodně paměti, tak jich chcete mít jen omezený počet.

Ano - a přesně proto, pokud se týče CPU, spouští Erlangovský scheduler tolik OS-vláken, kolik je jader Není to závislé na počtu (erlangovských) procesů.

Pokud je problém s pamětí nebo GC, tak ten u Erlangu taky s velkou pravděpodobností nebude, protože v Erlangu je GC lehčí než v Javě.

Pokud je problém s DB, tak se i v Erlangu musí použít pool, tam nijak nepomůže.

Jedině pokud by aplikace dělala nějaké intenzivní výpočty, tak by byl Erlang vyloženě nevhodná volba.

Procesy mohou pracovat s velkou datovou strukturou, přistupovat k jedné databázi, provádět operace na disku a podobně. Pokud každý Erlangovský proces načte do paměti několika-megabyteový soubor, tak vám dojde paměť úplně stejně jako v Javě.

Erlangovské procesy se opravdu hodí jen k udržování socketového spojení, kdy většinu času nic nedělají. Pro náročnější operace potřebujete frontu a omezení počtu souběžných operací.

[zboj]

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

Pokud je hlavní problém v tom, že se pro každý req spouští samostatné vlákno (a zároveň se OP chce zbavit Javy), tak by Erlang rozhodně pomohl. Dál v něm může každý req zpracovávat ve vlastním procesu a přitom se mu to krásně bude samo škálovat přes všechna dostupná jádra - žádný pool tam není potřeba, bude to fungovat samo, zabezpečí to erlangovský scheduler.

Jak řeší Erlang zásobníky, když udělám třeba milion procesů?

[b.]

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

Pokud je hlavní problém v tom, že se pro každý req spouští samostatné vlákno (a zároveň se OP chce zbavit Javy), tak by Erlang rozhodně pomohl. Dál v něm může každý req zpracovávat ve vlastním procesu a přitom se mu to krásně bude samo škálovat přes všechna dostupná jádra - žádný pool tam není potřeba, bude to fungovat samo, zabezpečí to erlangovský scheduler.

Jak řeší Erlang zásobníky, když udělám třeba milion procesů?

http://erlang.org/doc/efficiency_guide/processes.html

[zboj]

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

Pokud je hlavní problém v tom, že se pro každý req spouští samostatné vlákno (a zároveň se OP chce zbavit Javy), tak by Erlang rozhodně pomohl. Dál v něm může každý req zpracovávat ve vlastním procesu a přitom se mu to krásně bude samo škálovat přes všechna dostupná jádra - žádný pool tam není potřeba, bude to fungovat samo, zabezpečí to erlangovský scheduler.

Jak řeší Erlang zásobníky, když udělám třeba milion procesů?

http://erlang.org/doc/efficiency_guide/processes.html

Zajímavé, dík.

[BrainLess]

Malo info o tom kde to drhne .... ale co treba SSLOfload/Loadbalancing  ? Proc to hned prepisovat ?

[Mirek Prýmek]

To samé platí i při použití vhodných frameworků nebo knihoven.

Jo, může být. Akorát frameworky a knihovny (obzvlášť "enterprise" v Javě) vždycky hrozí dalším bobtnáním a hromadou balastu, kterou člověk nevyužije...

Pokud každý Erlangovský proces načte do paměti několika-megabyteový soubor, tak vám dojde paměť úplně stejně jako v Javě.

Tak samozřejmě. Pokud mám 50 req/s a pro každý musím načíst několik MB, tak se můžu dostat do úzkých. Ale to nemá žádné řešení. Pool ani fronta to nijak nevyřeší, maximálně můžou trochu vyhladit špičky.

Erlangovské procesy se opravdu hodí jen k udržování socketového spojení, kdy většinu času nic nedělají. Pro náročnější operace potřebujete frontu a omezení počtu souběžných operací.

A čím se jako principielně ta fronta od těch erlangovských procesů liší?! Tím, že můžu stanovit horní limit počtu obsloužených requestů? To většinou pochopitelně nikdo nechce.

Jo, je rozdíl mezi rychlým jazykem (C,C++,Java,Rust apod) a pomalým Erlangem, ale nevidím rozdíl mezi procesy a frontami (kromě toho, že fronty musím pracně obhospodařovávat).

[gll]

Erlangovské procesy se opravdu hodí jen k udržování socketového spojení, kdy většinu času nic nedělají. Pro náročnější operace potřebujete frontu a omezení počtu souběžných operací.

A čím se jako principielně ta fronta od těch erlangovských procesů liší?! Tím, že můžu stanovit horní limit počtu obsloužených requestů? To většinou pochopitelně nikdo nechce.

Jo, je rozdíl mezi rychlým jazykem (C,C++,Java,Rust apod) a pomalým Erlangem, ale nevidím rozdíl mezi procesy a frontami (kromě toho, že fronty musím pracně obhospodařovávat).

Rozdíl je v paměťové náročnosti. Výhoda je i v oddělení náročných úloh od ostatních. Nic obsluhovat nemusíte. Použijete hotové řešení.

Fronty úloh se používají i v Erlangu/Elixiru

https://github.com/akira/exq

[Filip Jirsák]

Jo, může být. Akorát frameworky a knihovny (obzvlášť "enterprise" v Javě) vždycky hrozí dalším bobtnáním a hromadou balastu, kterou člověk nevyužije...

To ale platí skoro o všech knihovnách a nástrojích – i s Erlangem nebo i s glibc dostanete spoustu balastu, který váš program nevyužije. Ale vadí to něčemu? Tohle budete řešit maximálně u mikrokontrolerů s omezenou pamětí, a to je evidentně jiný typ úloh, než jaký se tu řeší.

Tím, že můžu stanovit horní limit počtu obsloužených requestů? To většinou pochopitelně nikdo nechce.

Chce a fronty to právě řeší. Pokud zvládnete zpracovat 1 požadavek za sekundu, můžete začít zpracovávat první požadavek, dalších třeba 5 může čekat ve frontě a další přicházející požadavky můžete odmítat. Tím zajistíte, že se bude zpracovávat aspoň ten 1 požadavek za sekundu, a když se jich náhodou sejde o něco víc, tak si chvíli počkají, ale nakonec se to tím tempem 1 požadavek/s zpracuje. Což je pořád podstatně lepší situace, než když přijmete 50 požadavků, veškeré zdroje vyčerpáte jenom na jejich příjem a už vám nezbydou zdroje na zpracování ani jediného požadavku.

Rozdíl je v paměťové náročnosti.

„Procesy“ v Erlangu jsou velmi lehké, nejsou to skutečné procesy OS – nemyslím, že by byly paměťově nějak náročné.