Docela velká optimalizace

28.5.2005 20:36 | Přečteno: 1450× | Abíčko

Posledně jsem psal o plánu úpravy zdrojáků abíčka tak, aby některé SQL dotazy prováděl najednou. Někteří čtenáři nevěřili, že taková optimalizace povede k zásadnějším změnám ve výkonu. Teď se o tom můžeme přesvědčit na vlastní kůži.

Dosud jsem všude tahal objekty z databáze po jednom. Například když jste procházeli rubriku, tak se 25x vykonal SELECT pro jednu relaci a 25x jiný SELECT pro položku. A to nepočítám situaci, že články mívají většinou i diskusi. Napsal jsem novou funkci, která dokáže načíst pole objektů z databáze jediným dotazem. Těch 50 SQL dotazů vracejících jeden řádek je pro databázi mnohem náročnější než 2 dotazy po 25 řádcích. Primitivní logování ukázalo až čtyřnásobné zrychlení.

Následně jsem prošel celý zdroják a hledal, kde by se tato nová metoda dala použít. Míst bylo vážně hodně, prakticky všude. Takže jsem změnil skoro všechny servlety. Nemůžu vloučit chybu, přestože proklikání všech služeb Abíčka fungovalo na první pohled v pořádku. Pokud na něco divného narazíte, dejte mi vědět.

Tato změna asi nemusí být na první pohled z hlediska rychlosti vidět. Zvláště budete-li si prohlížet stránky, které zajímají většinu čtenářů a jsou tedy nacachované. Pro jednoho čtenáře se zrychlení bude pohybovat za běžné situace v desítkach milisekund. Hlavní změna ale je v tom, že pod silnou zátěží se bude Abíčko chovat lépe a nebude tak pomalé. Aspoň v to doufám. Tím vás ale nevyzývám k závodu v mirrorování . Jen věřím, že už jimi nebudeme tolik trpět.

       

Komentáře

[Yin]

Zdalo sa mi, ze nieco nieje v poriadku...

Ide to rychlejsie, ale divne je, ze mi v diskusii na otazku Potrebujem Refaktor C nikdo neodpovedal a nikdo mi neodpovedal.

A este divnejsie je, ze mi na blog eXtreme Programing 2 European Programing odpovedal len jeden clovek... ved to je oblubena tema vsetkych profesionalov... co je s Vami ludia? :)

[Michal Kubeček]

Zkusím si tipnout, v čem by mohl být problém. Za prvé: je dost možné, že se při dnešním počasí moc lidem nechtělo sedět u topícího počítače. Za druhé: nemám tušení, co je to refaktor a přitom se nepovažuji v programování zrovna za začátečníka, takže se dá očekávat, že lidí, kteří by vám s tím poradili, nebude zase tak mnoho. Za třetí: divit se, že vám okamžitě a střelhbitě během pár hodin nikdo neodpoví, je přinejmenším podivné…

[VícNežNic]

je dost možné, že se při dnešním počasí moc lidem nechtělo sedět u topícího počítače.

Dnes se ani nedalo nikam utéct Asi bych se měl preventivně začít učit finsky nebo tak nějak. Ach jo.

[Valoun]

Puhutko suomea? Vain englantia? Ei se mitään

Myslím, že tě Finsko nezachrání, dnes to tu pražilo 18°C. Málem jsem se upekl. A co hůř, zítra se vracím do Čech. To bude teprve peklo.

[VícNežNic]

18 stupňů je už celkem snesitelné

[jm]

Za druhé: nemám tušení, co je to refaktor a přitom se nepovažuji v programování zrovna za začátečníka

Juu, a ja tam chtel napsat neco ve smyslu WTF?!, ale pak jsem si to rozmyslel, abych nebyl za idiota.

[Martin Tůma]

Nic ve zlim, ale ten původní návrh musel bejt naprosto amatérskej, když bylo na každý jednotlivý řádek potřeba vykonat zvláštní SQL dotaz. Docela by mě zajímalo, jak vypadá struktura databáze abclinuxu, protože i tam bych tipoval, že to k optimálnímu návrhu bude mít hooodně daleko...

[Leoš Literák]

silna to slova. Proste jedna komponenta persistence to nepodporovala z duvodu jednoduchosti ci spise me lennosti.

[Michal Kubeček]

Proč hned amatérský? Větší množství malých dotazů nemusí nutně databázi zatěžovat o tolik více než jeden velký, zvláště jsou-li ty dotazy prakticky stejné a liší se jenom parametry. Záleží na tom, co je to za databázi, jak rychlé je spojení mezi databází a klientem, co je to za klienta a na mnoha dalších faktorech…

[Leoš Literák]

se odklada, nasel jsem v ni dost neprijemnou chybu ci nekompatibilitu. Jsem zvedav, jak rychle ji opravi.

[Filip Jirsák]

Můžu se zeptat, co je to za chybu? Mezi Jetty 5.1.1 a 5.1.3 mi také přestala fungovat aplikace, ale dozvěděl jsem se, že ta změna v Jetty není bug, ale feature Takže nezbylo, než přestat čekat na opravu Jetty a opravit aplikaci

[Leoš Literák]

bugzilla

[Filip Jirsák]

Mně tedy chování verze 5.1 připadá logičtější I když WEB-INF by to vypisovat nemělo nikdy, to je pravda. Ale pomoci by IMHO měla následující úprava web.xml (řekl bych, že parametr relativeResourceBase slouží právě k tomuto účelu):

<web-app>
    <display-name>test</display-name>
    <servlet>
        <servlet-name>TestServlet</servlet-name>
        <servlet-class>TestServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet>
        <servlet-name>default1</servlet-name>
        <servlet-class>org.mortbay.jetty.servlet.Default</servlet-class>
	<init-param>
            <param-name>relativeResourceBase</param-name>
	    <param-value>images/</param-value>
        </init-param>
        <load-on-startup>0</load-on-startup>
    </servlet> 

    <servlet-mapping>
        <servlet-name>TestServlet</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>
    <!-- static resources -->
    <servlet-mapping>
        <servlet-name>default1</servlet-name>
        <url-pattern>/images/*</url-pattern>
    </servlet-mapping>
</web-app>

[Leoš Literák]

Mi zase ne Kazdopadne diky za tip, s nim testovaci aplikace jede spravne. Problem ale je, ze takovych adresaru tam mam nekolik. Holt asi budu muset definovat default[1-5]

Ted jeste musim rozjet shellove skripty na spousteni.

[Filip Jirsák]

Já logiku vidím v tom, že servlet může být namapován na víc kontextů najednou, případně může být určen i koncovkou - a v těchto případech by implicitní mapování do podadresáře podle context-path už nebylo proveditelné.

Já také děkuji za tip Přemýšlel jsem pořád o tom, jak mít aplikaci mapovanou na /* a přitom používat DefaultServlet pro obrázky a spol. a nikdy mě nenapadlo mapovat DefaultServlet na něco jiného než na "/".

Jetty spouštím přes daemontools od DJB, údajně to tak je i na mortbay.org a osvědčilo se mi to nejlépe.

[Leoš Literák]

Ted jsem nasel svuj starsi patch pro Default servlet, s nim mi to zase pojede, jak jsem zvykly

Ja zase dekuji za tip na daemontools. Mohl bys napsat nejake zkusenosti? Jak na to, jake maji vyhody ..

[Filip Jirsák]

Skripty pošlu večer, až nebudu za firewallem a dostanu se na server Zkušenosti mám s daemontools zatím výborné, vpodstatě napíšu jen skript lehounce obalující java -jar jetty-start.jar a daemontools se postará o spouštění a zastavování. Navíc neustále monitoruje spuštěný proces a pokud by došlo k jeho ukončení, nastartuje jej znovu. Oproti různým distribučním skriptům, které se snaží uhádnout všechny možné parametry a jsou docela složité, tohle řešení je velmi průhledné.

Líbí se mi i to, že ukončení služby provádí daemontools zasláním signálu TERM, na což Jetty umí zareagivat správně. Distribuční skripty to mají většinou postavené na jetty-stop.jar, což trvá dlouho, a to občas nějaký správce služeb špatně snáší, a tvrdí, že službu nebylo možné zastavit

[Leoš Literák]

A jak zvlada situaci, kdy je jetty shozeno umyslne? Treba prave provadim upgrade databaze a kdyby mi daemontools automaticky detekoval, ze je jetty dole a spustil mi jej, tak by me to nepotesilo.

Proste jsou situace, kdy nechci, aby jetty bezelo. Da se nejak informovat daemontools, ze je jetty dole umyslne?

[Filip Jirsák]

svc -u /services/jetty spustí službu

svc -d /services/jetty jí zastaví

svstat /services/jetty vypíše aktuální stav (např. běží x vteřin, má se zastavit)

Takže když chci něco upravit nebo jen Jetty zastavit, použiju svc -d ..., přes svstat si ohlídám, kdy se Jetty skutečně ukončí, udělám úpravy a svc -u ... zase službu nahodím.