Fakta o faktech Microsoftu

Předně je nutno říci, že pokud jde o výsledky studie, tak Microsoft docela slušně „mlží“. Je sice pravda, že IIS mělo o 276 % vyšší maximální hodnotu propustnosti než Apache. Ale na statickém obsahu. A každý, kdo se ve WWW serverech trochu vyzná, ví, že Apache není vhodný server pro statický obsah. Apache je naopak dělán jako jednoduše rozšiřitelný server a vysoký výkon (na statických stránkách) nebyl nikdy jeho primárním cílem.

Od toho jsou tu jiné servery, například TUX, který byl do testu také zahrnut. V porovnání s ním byl výkon IIS vyšší maximálně o 51 %, což sice není nikterak lichotivé číslo pro Linux, ale také to není 276 %

Když už jsme u oné kampaně – je pikantní, že banner, který ji propaguje, je vlastně lživý. Tvrdí totiž, že onoho poměru bylo dosaženo na dvouprocesorové konfiguraci. Přitom ve skutečnosti to byla konfigurace čtyřprocesorová. Nicméně to není zas až tak podstatné.

Pojďme ale dále. Podstatnou informací je fakt, že studie byla sponzorována Microsoftem. Ten i dodal Windows 2003 Server. Red Hat byl získán standardní cestou bez „nadstandardního“ kontaktu s dodavatelem. Nutno říci, že firma provádějící test se při problémech s 8-procesorovou konfigurací pokoušela Red Hat kontaktovat skrze uživatelskou pdoporu, nicméně nebyla úspěšná.

Testovány byly Red Hat 8.0 s Apache (2.0.40), TUX běžel na Red Hat Advanced Server 2.1. Ten obsahoval kernel 2.4.9. Nad tímto faktem jsem nějakou dobu bádal. Kernel 2.4.9 sám o sobě byl totiž v době konání testu (duben 2003) již 20 měsíců starý, aktuální byl tehdy kernel 2.4.20, který je nesrovnatelně lepší. Nicméně Red Hat do kernelu částečně backportuje věci z novějších kernelů, a není tedy vůbec jednoduché zpětně říci, které tam byly a které ne.

Přitom aktuálnost verzí je dosti podstatná. V rámci testu byl porovnáván i Apache 1.3.23 na (výše zmíněném) Red Hat kernelu 2.4.9 versus Apache 2.0.40 na Red Hat 8.0 (verze kernelu nebyla ve studii uvedena). Novější Apache přitom dosáhl o 40 % vyššího výkonu než starší verze.

V dokumentu se popisuje poměrně podrobně nastavení systému. K němu bych měl následující výhrady:

1. Pro Windows se nastavuje maximální TCP port na 65536. Pro Linux se podobné nastavení neprovádí. Tak Linux mohl obsloužit méně aktivních spojení než Windows.
2. Pro Windows se nastavuje velikost bloku na filesystému na 64 respektive 32 kilobajtů. U Linuxu bylo ponecháno standardní nastavení (zřejmě 4 kB). Toto nastavení přitom může hodně ovlivnit výkon systému souborů.
3. Nikde jsem nenašel, že by se linuxový svazek připojoval s nastavením „-o noatime“. To má, podle mých zkušeností, významný vliv na výkonnost systému při čtení mnoha souborů z disku. Za normálních okolností se totiž při každém přístupu k souboru aktualizuje jeho access time v inode, který se musí zapsat na disk. Toto nastavení aktualizaci vypne.

Mohl bych mít ještě další výhrady, ale myslím, že tři výše uvedené plus částečně zastaralý SW (v porovnání s „horkou“ RC2 verzí Windows 2003 Server) mohly bohatě způsobit onen poloviční rozdíl ve výkonu.

Pro další testy (CGI a SSL) platí výše uvedené v plném rozsahu a připojují se další otazníky. Testovat CGI na výkon je, dle mého názoru, zcela nesmyslné. Tam, kde opravdu jde o výkon, se CGI skripty nepoužívají.

Výkon SSL ovlivnila ještě jedna věc. Zatímco IIS používal šifru RC4 se 128bitovým klíčem, na Linuxu byl použit 3DES se 168bitovým klíčem, který je až čtyřikrát pomalejší.

Teď bych ještě rád řekl něco obecně o podobných testech. Ačkoli se to nezdá, podobný test může být dokonce argumentem pro použití Linuxu. Nevěříte? Podívejte se na jeho výsledky. Ty říkají, že Apache na Linuxu na jednoprocesorovém PIII Xeonu na 900 Mhz zvládne přes šest tisíc dotazů za sekundu. Pokud počet dotazů na váš server bude řádově nižší (což na 99.9 % bude), můžete si v klidu vybrat, co chcete, podle dalších kritérií – cena, znalost prostředí, otevřenost, … A jestliže v těchto kritériích zvítězí Linux, můžete studii použít jako důkaz, že to zvládne i výkonově :-)

Podobné studie je totiž nutno brát s rezervou. Vždy platí, že testují nějaký konkrétní případ. A pro vás mají takovou cenu, jak moc se vaše situace přibližuje onomu konkrétnímu případu. Když provozujete server, který poskytuje krátké statické soubory, pak pro vás může být tato studie zajímavá – s přihlédnutím k chybám, pochopitelně.

Jestliže ale máte dynamický web, který sice obsluhuje jen pár desítek dotazů za sekundu, ale přesto nestíhá kvůli přenosu dat z disku, není takováto studie pro řešení vašeho problému přínosem.

Další otázkou je i kvalita studie – jak rozdíly v konfiguraci systému, tak v metodice. Například metodiku WebBenche, použitého v této studii, já osobně považuji za poněkud spornou, jelikož nemodeluje věrohodně zátěž. Ve zkratce: Měří maximální hodnoty propustnosti, místo aby zkoumala, kdy přestane server stíhat.

Dále od dobré studie nechtějte jen naměřené hodnoty. Dobrá studie by měla i analyzovat, proč jednotlivé měřené servery přestávají stíhat. Zda je problémem nedostatek paměti, vyčerpání CPU, nebo je úzké hrdlo v datových přenosech z disku či po sběrnici. Nebo jestli není omezení výkonu způsobeno nějakým nastavením systému (nedostatek file deskriptorů, …). To mi třeba v kritizované studii zcela chybí.

A nakonec ještě odkaz na PDF se studií.

P.S.: Děkuji všem autorům z konference, kteří se zúčastnili diskuse o testu, jmenovitě pak Jakubovi Urbancovi a Adamovi Přibylovi.