Mínus šest písmen = 20x zrychlení abíčka

21.3.2007 18:48 | Přečteno: 2567× | Abíčko |

Sypu si popel na hlavu. Konečně jsem odhalil, proč je server tak strašně zatížen a proč žádná moje optimalizace nezabírá.

Kdysi dávno, nevím odkud, nevím proč, jsem stáhnul volby pro virtuální stroj javy a nastavil jsem je pro jetty, pod kterou běží abíčko. Jedna z těch voleb je -Xint, která zakazuje Just In Time kompilátor a tudíž způsobuje, že java běží výhradně v interpretovaném modu. JIT překládá kód javy do instrukcí procesoru a na základě složitých analýz běhu provádí další optimalizace, díky kterým java může běžet stejně rychle (a někdy i rychleji) než zkompilovaný céčkový program. A já mu to nevědomky zakázal.

Na druhou stranu mi připadá neuvěřitelné, že přesto abíčko dokázalo obsloužit tolik návštěvníků (150 tisíc zobrazených stránek denně) a to velmi rychle. Zkusím malé přirovnání. Je to asi podobné, jako kdyby vám někdo svázal nohy k sobě, přes hlavu přetáhl černý pytel a poslal vás běžet maraton . Ty cache a optimalizace jsou asi dost účinné.

Ráno jsem tedy těch šest písmen smazal a restartoval server. Výsledkem je okamžité načítání stránek a prudký pokles zatížení serveru. Poslední měsíce bylo CPU neustále zatíženo nejméně na 99% a load se pohyboval mezi šesti až třiceti. Dneska ve špičce byl na úrovni 0,25.

       

Komentáře

[jozka]

No, hlavne, zes na to prisel, ne? Gratuluji!

[Milan Vít]

Tak výsledky tohoto zrychlení už jsou opravdu silně znát, stránky se načítají okamžitě, děkuji a taktéž gratuluji

[Leoš Literák]

Ale co ted budou delat vsichni kritici javy, kteri krici, jak je ta zla java pomala?

[tomm]

Budou konecne drzet usta

[Josef Kufner]

Prohlásí to za chybu měření a budou křičet dál

[niobi]

Java NIKDY NEBUDE RYCHLEJSI JAK C ... .-p

[msk]

Zavisi od prasackosti programatora. Pokial su obaja rovnake prasce, potom to zavisi od okolnosti, v niecom moze byt java rychlejsia, ale pausalne JE pomalsia a basta. A ked uz nic ine, tak aspon pamatove naroky nikto neuhada :o)

[Filip Jirsák]

a basta

To je ale pádný argument

[Fëannatar]

Hm... tvrdit, že výjimka potvrzuje pravidlo?

Jinak, super, abíčko opravdu chodí o hodně rychleji...

[Lu-Tze]

Smažou si taky těch šest písmen Ale teď vážně, myslím, že tím to nebylo, vypnul jsem si totiž nahrazování smajlíků za obrázky, takže příčinu bych viděl spíš v tom.

[Luboš Doležel (Doli)]

Kritici Javy budou říkat, že tohle by se u nativního jazyka nestalo

[Luk]

Tam se zase stávají jiné věci. Třeba debug verze místo release. Nejlépe ještě zkompilované s definovaným symbolem, který způsobuje, že se každou vteřinu pošle do syslogu několik tisíc ladicích zpráv

[Milan Vít]

Tyhle „kritiky“ a „experty“ snad někdy zajímaly argumenty?

[trekker.dk]

Taky řešení... pokud by se náhodou objevil někdo s rozumnými argumenty, strčíme ho rovnou (nebo pokud možno předem) do uvozovek a máme od něj klid.

[Milan Vít]

Pokud by se objevil někdo s rozumnými argumenty, nejsou pro něj uvozovky to pravé smetanové, leč já měl zatím jen to „potěšení“ s lidmi hlásajícími „argumenty“ jako: „Fůůůj, to nebudu používat, to je v Javěéé, to je určitě pomalééé.“

[Michal Kubeček]

Ono to bývá v praxi spíš obráceně: "Fuj, to je ale pomalý krám… jak je to jen možné… hele, ono je to v Javě…" Samozřejmě, nemusí to být problém Javy jako takové, možná jen toho, že čím je framework pohodlnější, tím menší nároky klade na schopnosti vývojáře a tím neschopnější vývojáři se pro práci v něm najímají.

[trekker.dk]

JIT překládá kód javy do instrukcí procesoru a na základě složitých analýz běhu provádí další optimalizace, díky kterým java může běžet stejně rychle (a někdy i rychleji) než zkompilovaný céčkový program.

Trošku zjednodušeně: JIT překládá kód Javy na nativní a díky optimalizacím může ten program běžet rychleji než zkompilovaný céčkový kód.

Nebo ještě zjednodušeněji: optimalizovaný nativní kód může běžet rychleji než nativní kód. To by jeden neřekl.

Když byl JIT vypnutý, ábíčko se vleklo --> interpretovaná Java JE pomalá. Když se přeloží do nativní podoby, funguje mnohem rychleji, ale už to v podstatě není Java (procesor podle instrukcí těžko pozná, v jakém jazyce ten program byl napsán)

[Leoš Literák]

interpretovaná Java JE pomalá. Když se přeloží do nativní podoby, funguje mnohem rychleji, ale už to v podstatě není Java (procesor podle instrukcí těžko pozná, v jakém jazyce ten program byl napsán)

Pak ale neni duvod zavrhovat javu. Ciste interpretovana java se vyskytovala tak v roce 1996, od te doby vznikly JIT kompilatory a byly vyladeny k maximalni optimalnosti. Java je narocna na pamet, ale v realnych aplikacich z hlediska rychlosti nezaostava za nativnimi programy (tim mam na mysli, ze by byla o nasobky ci rady pomalejsi).

[qk]

no ona ani ta narocnost na pamet, pokud se clovek pohybuje ve v radu desitek mega neni tak hrozna, staci si spravne nastavit mnozstvi pameti pro virtualni stroj. Je to klasicke dilema jestli pamet nebo rychost, pri vetsi pameti se tak casto neprudi garbage collector a naopak.

[trekker.dk]

Pak ale neni duvod zavrhovat javu.

Jak kde... pokud jde o program, který běží několik týdnů v kuse někde na serveru (žádný příklad mě zrovna nenapadá ) a JIT kompilátor ho odladí, tak je Java stejně dobrý jazyk jako většina jiných.

Problém je, že v Javě dost lidí vyvíjí uživatelské programy, které se spustí, vykonají nějakou práci a ukončí se, to vše interpretovaně a tedy většinou zbytečně pomalu. Takové nasazení Javy mi přijde, když použiju tvoje slova, "zavrženíhodné".

[Filip Jirsák]

Nemyslím, že by interpret byl důvod nějakého výrazného zpomalení. Na aplikace psané třeba v Pythonu si asi nikdo nestěžuje, že jsou interpretované a tudíž pomalé. Ale Java na desktopu na tom úplně dobře není, to je fakt. Teď se ale vývojáři Javy na desktop hodně zaměřují, takže se dá očekávat, že dojde ke zlepšení i v tomto směru. Prostor na to je

[trekker.dk]

Nemyslím, že by interpret byl důvod nějakého výrazného zpomalení.

Abych pravdu řekl, nechci se pouštět do nějakých porovnání jak velké zpomalení interpreter způsobí (Když to zjednoduším, Leoš v nadpisu tohoto blogu tvrdí že dvacetinásobné.) To, co tvrdím, je, že to zpomalení je zbytečné, když je tu možnost kód zkompilovat a interpreter úplně vynechat.

[Filip Jirsák]

Vždy je to něco za něco. Kompilace něco stojí, i proto má Sunovské JRE dva režimy – v prvním se optimalizuje méně (tedy optimalizace je hotová dřív), takže start je rychlý, ale aplikace pak běží pomaleji. Ve druhém aplikace sice startuje dýl, ale optimalizuje se víc. Běh ve virtuálním prostředí pak samozřejmě taky má nějaké výhody – ať už jsou to třeba možnosti dynamické optimalizace za běhu, nebo větší ochrana a oddělení programu a ostatního prostředí. To třeba dnešní procesory neumožňují a je to přidaná hodnota JVM.

Stejně by se dalo říct, že je zbytečné používat operační systém. Pokud bude program přistupovat přímo k hardwaru, nebudou se "zbytečně" přepínat kontexty uživatelského prostoru a jádra a odpadnou "zbytečná" systémová volání, bude program taky rychlejší. Operační systém ale poskytuje nějakou přidanou hodnotu, a aplikacím se většinou vyplatí běžet pomaleji za cenu využití této přidané hodnoty. Samozřejmě vždy záleží na poměru cena/výkon, ale myslím, že obecně se budou snižovat náklady na tyhle různé virtualizační vrstvy. Ne nadarmo se v poslední době řeší vše možné kolem virtualizace – ať už je to podpora virtualizace v Linuxovém jádře, nebo boom VMware a jemu podobných programů. Výpočetní výkon už na to máme, takže si můžeme dovolit luxus toho mírného zpomalení, když tím získáme větší přenositelnost nebo větší bezpečnost.

[trekker.dk]

Vždy je to něco za něco. Kompilace něco stojí, i proto má Sunovské JRE dva režimy – v prvním se optimalizuje méně (tedy optimalizace je hotová dřív), takže start je rychlý, ale aplikace pak běží pomaleji. Ve druhém aplikace sice startuje dýl, ale optimalizuje se víc.

Tady možná došlo k nedorozumění - já mluvil o možnosti kód zkompilovat z jazyka typu C++.

Stejně by se dalo říct, že je zbytečné používat operační systém. Pokud bude program přistupovat přímo k hardwaru, nebudou se "zbytečně" přepínat kontexty uživatelského prostoru a jádra a odpadnou "zbytečná" systémová volání, bude program taky rychlejší.

Tohle srovnání tak trochu pokulhává - tohle už tu kdysi bylo a mělo to tu nevýhodu, že šlo spustit jenom jeden program naráz. OS je mezivrstva navíc, ale dle mého mínění ta možnost spouštět víc programů naráz a zabránit jim, aby se mezi sebou chybně ovlivnily, stojí za ten ztracený výkon.

JVM nic takového neposkytuje, pro každý spuštění program v Javě se spouští znovu (a rozhodně neříkám, že je to špatně - proč by JVM měl řešit přepínání úloh, když to samé dokáže OS vyřešit za něj). Podle mě ta přidaná hodnota JVM (bez optimalizací) nestojí za to.

Samozřejmě je tu velký prostor pro zlepšení. Napadá mě například situace (nevím, jak moc je reálná), kdy by JVM uměl provést optimalizace již při vývoji a testování programu a výsledky do programu uložit, aby je na nejrozšířenějších platformách vůbec nebylo nutné dělat (a aby se při opětovném spuštění mohly rovnou použít). To by podstatně měnilo situaci.

[Leoš Literák]

Java 5 dokaze sdilet cast pameti mezi ruznymi JVM v ramci jednoho systemu. Takze celkove mnozstvi zabrane pameti se nerovna poctu JVM. Nicmene realny prinos jsem nemeril. Kazdopadne vyvoj jde smerem k tomu, aby na pocitaci existovala jedina JVM, ktera bude spoustet jednotlive aplikace.

[Marek Bernát]

Takze celkove mnozstvi zabrane pameti se nerovna poctu JVM.

No, to asi môže dosť ťažko; na jednej strane je veličina, ktorá sa meria v bajtoch a na druhej bezrozmerná

Inak skvelá práca, ábičko je rýchle ako blesk.

[Filip Jirsák]

Podle mě ta přidaná hodnota JVM (bez optimalizací) nestojí za to.

Dost lidí má asi jiný názor, když vznikají věci jako .NET, podpora virtualizace v Linuxovém jádru nebo virtualizační software. Někdy se to prostě vyplatí a jindy ne – záleží dokonce i na tom, co vše započítáte, takže i u jednoho a toho samého projektu může mít někdo názor, že přidaná hodnota VM je menší, než ztráta výkonu (protože počítá čistě efetktivitu běhu programu), někdo započítá i náklady na vývoj a údržbu programu, a najednou se nějaká přidaná hodnota vykoupená zpomalením vyplatí.

Samozřejmě je tu velký prostor pro zlepšení. Napadá mě například situace (nevím, jak moc je reálná), kdy by JVM uměl provést optimalizace již při vývoji a testování programu a výsledky do programu uložit, aby je na nejrozšířenějších platformách vůbec nebylo nutné dělat (a aby se při opětovném spuštění mohly rovnou použít). To by podstatně měnilo situaci.

Při vývoji asi ne, během vývoje se program používá dost netypicky. Ale keš zkompilovaného kódu, která by přežila restart JVM, je jedno z možných řešení. Další možností je sdílení tříd mezi běžícími JVM (implementováno v Sunovském JRE od verze 1.5).

Vzhledem k tomu, že např. gcj nejspíš nepředstavuje nějaké výrazné zrychlení proti klasické JVM, je spíš než kompilace do strojového kódu důležitá rychlost startu běhového prostředí (GC, classloader, "základní" třídy). Tedy spíš pomůže volitelné ponechávání JVM v paměti a nějaké optimalizace rychlosti startu GUI. Což jsou shodou okolností všechno věci známé z programů psaných v C++ – ať už je to ponechávání v paměti u OOo, Mozilly nebo MSIE, nebo různé prelink techniky grafických prostředí na Linuxu. Je vidět, že programy v Javě i C++ řeší vlastně stejné problémy

[Leoš Literák]

na filtry bezici par sekund fakt java vhodna neni. Ale bezne pouzivam (davno) java aplikace na desktopu a prijdou mi v pohode (XXE, SQuirrell) ..

[trekker.dk]

Možná... všechny programy v Javě, které jsem na desktopu vyzkoušel, se nažraly paměti a chodily jak zpomalenej film, takže pokud existuje alternativa, tak se Javě vyhýbám.

[Filip Jirsák]

Tohle je jedna ze základních vlastností Javy jako platformy – programy se neoptimalizují při překladu, ale až za běhu, kdy má překladač k dispozici mnohem víc informací, jak kód skutečně zoptimalizovat (a na druhou stranu, JIT nepřekládá automaticky vše do strojového kódu, překládá jen ten kód, který se pouští často). To je také důvod, proč může být Java někdy rychlejší než klasický (byť kompilátorem zoptimalizovaný) C-čkový kód. JVM třeba může zjistit, že nějaký if v 99,9 % projde větví else, takže vytvoří takový strojový kód, aby procesorové cache a "počítání napřed" šlo touhle větví (to je jen příklad, nevím, zda nějaká JVM konkrétně tohle dělá). Samozřejmě, V C si můžete takovou JVM naprogramovat taky, pak bude výsledný program i stejně rychlý – ale může to být zrychlení oproti klasickému Cčkovému ifu optimalizovanému pouze kompilátorem a procesorem.

[pele]

Paráda

[vencour]

Blahopřeju k odvaze se veřejně přiznat. Máš mé silné sympatie.

[User682]

Hezke. Klasika. Takove zaseky ma asi kazdy linuxovy portal. Dalo by se vypravet.

Pridam perlu.

Porad je to lepsi nez u nejmenovane spolecnosti s benzinem, kde zjistili, ze denni davka se pocita uz ne 4 hodiny, ale uz 23 hodin a tak dale. Pak prisel typ a stahnul to na 15 minut a rekl, ze by to slo jeste stahnout za dalsi penize.

bye gf

[Boris Dušek]

U podobných bugů, které mají vážné následky, ale až směšně malé příčiny, a které člověk v potu tváře odhaluje hodiny a dny, si vždycky vzpomenu na větu z Pelíšků: "Hezký. A přitom taková blbost ... "

[thingie]

No, ale teď ti zase nekoupí nový server, takže zase taky nic moc

[Snilard]

Neznalost je hrozná vlastnost, kterou bohužel trpíme všichni. Přiznat se k ní je odvážné.
Dobrá práce :)

[Luboš Doležel (Doli)]

Myslím si, že tady to nebyla neznalost, ale spíš jen opomenutí / přehlédnutí

[Michal Kubeček]

To mi trochu připomíná, jak jsem po půl roce provozu náhodou zjistil, že jsem z chladiče na procesor (nějaký 600 MHz Duron) před nasazením zapomněl sundat ochrannou pásku, takže kromě tepelně vodivé pasty byl procesor od chladiče oddělen ještě tepelně nepříliš vodivou vrstvou nějakého plastu…

[peterh]

Fakt je to o poznanie rýchlejšie. Asi ten HW na čom beží abčko nieje až tak na zahodenie . Btw. v lynxe to naskakovalo okamžite aj predtým.

[alblaho]

Myslím, že to potvrdilo jednu věc: procesorového výkonu je dost, jediné, na co webové servery čekají, je disk (databáze). Bych rád viděl, co by se stalo, kdybys dvacetkrát zpomalil disk

[Haaja]

Gratuluji k odhaleni....

[happy barney]

blbá otázka: zvládlo by to gcj ?

[Leoš Literák]

Netusim, nemam k temto nastrojum duveru. Mozna uz se situace vylepsila, ale pred lety byla jejich funkcnost tragicka. Nemam potrebu zjistovat, zda se situace zlepsila ci ne., preferuji JVM od tvurce jazyka.

[happy barney]

uff, tak argument pred lety byla jejich funkcnost tragicka som teda nečakal

[Leoš Literák]

To neni argument. Ptal ses me, zda by to gcj zvladlo a ja odpovedel, ze nevim.

[happy barney]

ok, pardon, nevhodne zvolené slovo argument. Spätne skúsim použiť slovo výrok.

[Filip Jirsák]

A co argument – podle mého to nestojí za to, výkon by byl buď srovnatelný nebo horší a přineslo by to spoustu problémů s odladěním? A další pádný argument – Java 5 ještě není gcj plně podporována. Myslím, že gcj je slepá cesta…

[xsubway]

Díky za upřímnost

[Michal Vyskočil]

Můžeš to poslat Sunům jako ukázkový příklad o kolik je JIT schopno zrychlit běh reálné aplikace ...

[okbob]

diky tomu jsi ale vychytal vsechny ostatni bugy . Soft by se mel psat na pomalejch strojich, by to pak userum behalo jak splasena kuna

[zde]

Konec dobrý, všechno dobré.

[elviin]

Taky se pridavam k pochvale a uznani. Abicko se mi moc libi! Ale ... ale mam vyhradu k te rychlosti javy obecne. Jak je napsano vyse, vyjimka potvrzuje pravidlo. To, ze to beha hezky tady neni argument pro to, ze to beha hezky jinde. A jak bych si to ze srdce pral. Ano mozna Java je dobra pro ws aplikace, ale na desktopu je to nenasyta, dalsi vmware (v cem je vlastne rozdil?). Proc mi bezi napr. 3 javy s loadem 100-200MB pro tri aplikace? Jdu hledat ten switch pro Matlab, Elcipse, Netbeany, Poseidon ...

[Filip Jirsák]

Ta paměť ale není všechna skutečně používána, je to jenom naalokovaná paměť. Třeba eclipse na mém počítači (ve Windows) má hned od začátku přes 1 GB, a počítač fyzicky má jen 1 GB. Dál tu běží z těch větších ještě J2EE kontejner (400 MB), Outlook (300 MB), Firefox (350 MB). A ten počítač neswapuje ( to začne, až když do toho spustím ještě MSIE 7 a VMware). Čistá Java je jen ten J2EE kontejner, eclipse používá spoustu nativních knihoven. Mně osobně tedy připadá daleko nepochopitelnější ten Outlook a FF. Java také paměť využívá trochu jiným způsobem – naalokuje si od systému větší kus paměti, kterou si pak spravuje ve vlastní režii (GC). Taky jsem měl dříve pocit, že Java chce víc paměti, ale když to porovnám s FF, OOo, tak mám pocit, že víc paměti chce všechno… V té Javě se alespoň něco pro nižší paměťovou náročnost dělá.

Docela by mne zajímalo, kolik RAM máte a jaké aplikace na tom PC provozujete, protože 1 GB RAM podle mne už na Javu na desktopu stačí, eclipse trochu víc RAM neuškodí. Ne že by mne ty nároky na paměť těšily, ale obávám se, že je to všeobecný trend a paměťová nenažranost Javy se vyřešila/řeší tím, že takové paměťové nároky začínají být běžné.

[Josef Kufner]

Co ty programy s tolika megabajty paměti dělají? Když se podívám vedle na stůl, tak tam stojí stařičká 386, která má v sobě 8 MB RAM (ano, osm megabyte) a Win95 + WordPerfect na tom běhal skoro stejně rychle jako OpenOffice 1.3 na 2.4 GHz Celeronu. 8 MB vs. 512 MB, 40 MHz vs. 2400 MHz.

Tohle prostě není v pořádku. Oba programy umí přibližně totéž a GUI je víceméně stejně pohodlné, vlastně ten WordPerfect byl lepší. Jo, v Linuxu je cesta od programu k uživateli delší a jádro si taky něco ukousne, ale to nebude způsobovat takle propastný rozdíl (není to zanedbatelné, ale není to moc).

Co ty programy s tou pamětí teda dělají?

[Luk]

Programy si syslí paměť, protože by ji třeba mohly v budoucnu potřebovat. A je rychlejší a jistější ji mít k dispozici, než o ni žádat systém.

Legrace ale je, že na Linuxu se velice často používá overcomitting, takže jádro zvesela rozdává paměť, kterou vůbec nemá. Ještě legračnější to pak je, když se programy rozhodnou tu paměť opravdu využít a ono jí není dost. Ten, kdo má Černého Petra, musí z kola ven (což vůbec nemusí být hlavní viník krize)

[David Jaša]

To ale neodpovídá na otázku, proč dnešní OOo řádově více paměti, kterou chtěly kancelářské balíky před 10 - 12 lety, a přitom dělají stále to samé...

[Leoš Literák]

Pokrok?

[petr_p]

Preci existuje jedna konstanta: porizovaci cena. Vsimne te si, ze v roce 1992 v CR stal kancelarsky pocitac (386, 14" barevny monitor a jehlickova tiskarna, plus nejaky SW) 30000 Kc. Dneska sestava pro stejne ucely stoje zhruba stejne.

Proste lidi jsou ochotni utratit urcitou castku a podle toho vyrobci SW a HW tvori nabidku.

Je pravda, ze v tehdejsi kancelari jste si k tomu soubezne nepustili hudbu a webovy prohlizec a ochranu pred neopravnenym pouzitim (napr. operacni system) atd., ale taky to nikdo nevyzadoval.

Na druhou stranu je treba priznat, ze kancelarska prace je preci jen efektivnejsi (vice vyprodukovanych dokumentu za jednotku casu) dnes nez pred 15 lety. Takze jisty pozitivni trend tu je.

[tomfi]

Jenom jestli je více dokumentů známkou lepší produktivity... jestli ty dnešní dokumenty mají stejnou entropii :)

[Leoš Literák]

Dnesni load:

0.05 0.18 0.21 1/220 10754

To je rozdil