Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Onstn 28. 04. 2017, 12:48:26
-
Mám dotaz, jestli máte někdo podobnou zkušenost. Máme relativně velkou aplikaci v Javě, je to webová služba s cca. 5000 požadavky za minutu, která (když to hodně zjednoduším) ukládá data ze senzorů (IoT) do databáze, která se pak na pozadí dále zpracovávají. Máme to na serveru s 24 vlákny a 64GB RAM a vše šlape, jak má. Nedávno někdo přišel s tím, že bude experimentovat se Swiftem. Nevím, jaké frameworky pro Swift existují, kolega použil něco od IBM, a když asi po týdnu skončil, jeho implementace dělá to samé, ale vytížení CPU kleslo ze 40% na asi 5% a náročnost na paměť z 50GB na necelých 8 (12 ve špičce, když se sejde výrazně více požadavků). To vzbudilo mou pozornost, trochu jsem googlil a našel poměrně hodně článků, jak někdo přešel z Javy, node.js nebo Pythonu na Go nebo Rust (Swift ne, ale ve všem ostatním je pozoruhodná shoda), čímž ušetřil 90% prostředků (serverů/času CPU/paměti, liší se článek od článku). Má otázka je, co mají zmíněné jazyky lepšího oproti Javě/node.js apod., že je rozdíl ve výkonu a spotřebě prostředků tak výrazný?
-
Nepotrebuji 63GB pro garbage collector :)
-
Problem byva, ze ludia nevedia uz programovat, na vsetko v jave nadrbu 10 frameworkov, potom to ide pomaly.
Kym nenapisete, ake technologie projekt pouziva, je to len na urovni "bla bla".
-
Jo swift https://swift.org/getting-started/#using-the-lldb-debugger
opravdu vychází rychlejší a méně náročnější na paměť - nemá GC jeno ref Counter.
https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memory-management-method-of-garbage-collection-like-in-Java
http://stackoverflow.com/questions/36020636/how-is-arc-in-swift-different-from-garbage-collector-in-java
-
Nepotrebuji 63GB pro garbage collector :)
Aneb slovy klasika (možná Chris Lattner, už nevím): "Tracing GC is a poor man's automatic memory management." Ani vlastně nevím, jestli to je narážka na Android.
-
Nepotrebuji 63GB pro garbage collector :)
Aneb slovy klasika (možná Chris Lattner, už nevím): "Tracing GC is a poor man's automatic memory management." Ani vlastně nevím, jestli to je narážka na Android.
Ahoj ZBOJ.... poslal jsem ti email na tvuj registracni email....
-
Tak nizke naroky, tedy prijmou WS call a insertovat do DB musi Java zvladnout s prstem v nose.
Osobne typyju, ze to nekdo postavil na zbytecne slozitych frameworcich, ze kterych vyuziva 5% funkcionality.
Pokud na ony proste zapisy do DB pouziva Hibernate s JSQL a ORM mappingem a nedejboze se zapnutymi transakcemi na Java urovni, pokud na WS pouziva builtin J2EE 7 container, bude to nenazrane.
Tyto frameworky maji primarni cil udelat robustni a udrozovatelnou business aplikaci, hodi se nejlepe za zapezpecene komplexni business procesy, na takovou trivku je to overkill.
Jako prvni pokus bych to skusil predelat do Apache Camel spousteneho ze Spring Boot.
Pokud by ani toto nestacilo, doporucuju jit na nizsi uroven, do Spring Bootu strci nejakou lightweight implementaci WS (Gretty), nizkourovnovy JDBC pool (C3PO, DBCP) a pres prepared statementy cpat data do DB naprimo.
-
Jako prvni pokus bych to skusil predelat do Apache Camel spousteneho ze Spring Boot.
Rovnou přeskočit. Rozdíl je hlavně v tom že místo "enteprise byrokracie" je tam "hip magie" - z hlediska performance jsou oba dva koncepty jsou srovnatelní žrouti.
Je tu ale ještě jedna věc, kterou bych tipnul - možnáje tam docela dost zpracování jednoduchých dat, od dekódování nějakého binárního protokolu až po nějaké nějaké konverze, agregace a podobně, možná i nějaké maticové operace? Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Nicméně, to jsou jenom takové špekulace.
-
[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.
-
[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.
Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.
-
[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.
Seznam/pole čísel o dynamické velikosti.
Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.
Seznam/pole čísel o dynamické velikosti.
-
[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.
Seznam/pole čísel o dynamické velikosti.
Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.
Seznam/pole čísel o dynamické velikosti.
samozřejmě to jde, jen ne genericky.
-
[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.
Seznam/pole čísel o dynamické velikosti.
Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.
Seznam/pole čísel o dynamické velikosti.
Pole dynamickej velkosti sa da implementovat cez pole statickej velkosti. Dvojrozmerne pole sa da implementovat ako jednorozmerne. Zavisi od toho, aka funkcionalita je potrebna a usit to vhodne pre danu situaciu.
-
[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.
Seznam/pole čísel o dynamické velikosti.
Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.
Seznam/pole čísel o dynamické velikosti.
samozřejmě to jde, jen ne genericky.
Tak se ukaž. Aby to nedopadlo jako s preemptivním schedulingem v Go...
-
[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.
Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.
Seznam/pole čísel o dynamické velikosti.
Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.
Seznam/pole čísel o dynamické velikosti.
Pole dynamickej velkosti sa da implementovat cez pole statickej velkosti. Dvojrozmerne pole sa da implementovat ako jednorozmerne. Zavisi od toho, aka funkcionalita je potrebna a usit to vhodne pre danu situaciu.
Tak to jde vždy, ale nejde udělat dynamické nativně, což je taky to jediné, co jsem tvrdil.
-
Tak to jde vždy, ale nejde udělat dynamické nativně, což je taky to jediné, co jsem tvrdil.
Kefalín, čo si vy predstavujete pod takým slovom "nativně"?
-
Mám dotaz, jestli máte někdo podobnou zkušenost. Máme relativně velkou aplikaci v Javě, je to webová služba s cca. 5000 požadavky za minutu, která (když to hodně zjednoduším) ukládá data ze senzorů (IoT) do databáze, která se pak na pozadí dále zpracovávají. Máme to na serveru s 24 vlákny a 64GB RAM a vše šlape, jak má. Nedávno někdo přišel s tím, že bude experimentovat se Swiftem. Nevím, jaké frameworky pro Swift existují, kolega použil něco od IBM, a když asi po týdnu skončil, jeho implementace dělá to samé, ale vytížení CPU kleslo ze 40% na asi 5% a náročnost na paměť z 50GB na necelých 8 (12 ve špičce, když se sejde výrazně více požadavků). To vzbudilo mou pozornost, trochu jsem googlil a našel poměrně hodně článků, jak někdo přešel z Javy, node.js nebo Pythonu na Go nebo Rust (Swift ne, ale ve všem ostatním je pozoruhodná shoda), čímž ušetřil 90% prostředků (serverů/času CPU/paměti, liší se článek od článku). Má otázka je, co mají zmíněné jazyky lepšího oproti Javě/node.js apod., že je rozdíl ve výkonu a spotřebě prostředků tak výrazný?
Stačilo mi přečíst 64 gb ram a 5k requests per MINUTE a skončil sem.
Chyba neni v Jave, ani v tracing GC.
Chyba je v idiotech co to psali.
Just for fun... RC je jen jina forma GC ktera se hodi jen někde a jen na něco. Oproti tracing gc ma totiž dost nevyhod.
-
Tak to jde vždy, ale nejde udělat dynamické nativně, což je taky to jediné, co jsem tvrdil.
myslíš něco jako realloc? To nefunguje spolehlivě nikde.
-
Tak se ukaž. Aby to nedopadlo jako s preemptivním schedulingem v Go...
Když překročím velikost, alokuji nové pole dvojnásobné velikosti a to staré do něj překopíruji.
-
Nepotrebuji 63GB pro garbage collector :)
Aneb slovy klasika (možná Chris Lattner, už nevím): "Tracing GC is a poor man's automatic memory management." Ani vlastně nevím, jestli to je narážka na Android.
ty zboji, jedinej poor man si tady tak možná ty :D
-
Pozerate RSS? Treba pouzit nejake profiling tooliky, pozriet ci nie je prilis casu straveneho v gc, urobit heap dump a pozriet sa cez eclipse memory analyzer v com je problem. Mozno ten heap je prazdny a je zle nastavene GC. Mam taku skusenost, ze takto vyziera heap spracovanie XML (napr SOAP). GC v jave funguje trosku inak ako reference counting, takze s tym ze by si sa dostal na uroven swiftu zabudni. Navyse swift nepotrebuje metaspace a code cache a ine zrace pamate. Na druhu stranu sa tam daju lahko narobit mem leaky.
Inac ten IBM framework (kitura) bol trochu rozozrany, efektivnejsi by mal byt perfect.org.
-
Pozerate RSS? Treba pouzit nejake profiling tooliky, pozriet ci nie je prilis casu straveneho v gc, urobit heap dump a pozriet sa cez eclipse memory analyzer v com je problem. Mozno ten heap je prazdny a je zle nastavene GC. Mam taku skusenost, ze takto vyziera heap spracovanie XML (napr SOAP). GC v jave funguje trosku inak ako reference counting, takze s tym ze by si sa dostal na uroven swiftu zabudni. Navyse swift nepotrebuje metaspace a code cache a ine zrace pamate. Na druhu stranu sa tam daju lahko narobit mem leaky.
Inac ten IBM framework (kitura) bol trochu rozozrany, efektivnejsi by mal byt perfect.org.
Než řešit profiling, to už je lepší použít přímo jazyk, ve kterém to jede svižně.
-
Hej, to urcite bude lacne. Ale mozno je to nejaka mini apka.