HTTP komprese a SharePoint

Dovolím si říci, že datová komprese je v rámci IIS tak trochu zapomenutým pojmem. Když se IT administrátorů na tuto funkci ptám, většina z nich dokáže rámcově říci k čemu je to dobré, ale překvapivě velmi málo z nich ji skutečně na svých webových serverech používá. Proč? No to víte, ve výchozím nastavení to není zapnuté. A ikdyž to zapneme v rámci grafického rozhraní IIS konzoly, tak to nefunguje, nebo to nefunguje tak, jak chceme a pokud to možná i funguje, nevíme jak. A přitom je to tak snadné a při správném a citlivém nastavení i užitečné!

Komprimovat ano či ne? Ano, ale s rozmyslem!

Klasickou komprimaci souborů jistě znáte, “sbalením” do ZIP, RAR či jiných archivů se zmenšuje jejich datový objem. Možná víte, že i Microsoft Office Open XML transparentně používá ZIP kompresi (přejmenujte si libovolný DOCX, PPTX, XLSX soubor na ZIP a již víte, kde je zakopán pes). Tento článek tedy popíše, jak podobnou kompresi dat využít i v okamžiku jejich přenosu mezi webovým serverem a klientem.

Zjednodušeně řečeno funguje komprese tak, že nahrazuje opakující se sekvence bajtů. Výhodné je tedy využít ji pro textová data (soubory typu HTML, CSS, JS…). Naopak nevhodné je snažit se kompresi využít pro již jednou komprimované soubory (JPEG, GIF, MP3, WMV, ZIP…). Fajn, kompresí tedy šetříme přenesené datové objemy mezi serverem a klientem, ovšem nic není zadarmo. Pozor si musíte dát na procesorovou zátěž daného web serveru. Je-li již nyní váš web server na tom s procesorovým časem bídně, zapnutí komprese mu moc nepomůže.

Co na to SharePoint a jak HTTP komprese funguje?

V rámci SharePoint portálů můžeme velmi snadno využívat předpřipravené nástroje pro tvorbu nových řešení a služeb, zároveň máme nicméně velmi malou kontrolu nad tím v jaké finální podobě se HTML kód posílá na stranu klientů.

Pamatujte, že SharePoint využívá jak statické, tak dynamické soubory. Téměř všechno z “_layouts” a “_vti_bin” je statické (kromě několika přítomných ASPX a ASMX stránek), a všechno z rootu je dynamické, neboť se buď jedná o ASPX stránky či obsah poskytovaný pomocí owssvr.dll (ISAPI extension využívaný mimo jiné při vytváření či mazání SharePoint seznamů, http://www.server.com/subweb/_vti_bin/owssvr.dll?Cmd=NewList a vykreslování HTML obsahu.). Při nastavování HTTP komprese je tedy třeba zohlednit jak statický, tak dynamický obsah. Ostatně typickou skupinu typů souborů, u nichž kompresi zapínáme, vidíte níže v ukázce skriptu.

Přijde-li na IIS požadavek, dojde nejprve ke kontrole, zda klient kompresi podporuje a jaké podporuje její typy, a to pomocí HTTP hlavičky Accept-Encoding. Umí-li server používat klientem podporované typy komprese, tak svou odpověď zkomprimuje příslušným kompresním algoritmem (GZIP, DEFLATE) a odešle odpověď klientovi. Zároveň mu pomocí hlavičky Content-Encoding sdělí, jaký kompresní algoritmus pro komprimaci odpovědi použil.

Je-li klientem poptáván statický obsah, IIS 6.0 nejprve ověří, zda byl daný obsah již dříve požadován a je tedy uložen v komprimované podobě v lokální mezipaměti (cache, standardně %Windir%\IIS Temporary Compressed Files). Není-li komprimovaná verze v mezipaměti nalezena, pak server odešle klientovi nekomprimovanou verzi obsahu a na pozadí provede jeho komprimaci a uložení do lokální mezipaměti, odkud je při dalších požadavcích klientům opětovně poskytován. Dopad na zátěž procesoru tedy není velká, protože procesor nemusí data znovu komprimovat.

Dynamický obsah však “kešován” serverem není, IIS neukládá komprimované verze dynamického výstupu do mezipaměti. Přijde-li tedy na server požadavek na dynamický obsah, pak data, která server klientovi posílá, jsou znovu generována a komprimována vždy při každém požadavku, což znamená nárůst procesorové zátěže.

A pozor – chcete-li využít kompresi i pro soubory uložené v dokumentových knihovnách, pak vězte, že se de-facto jedná o data poskytovaná již zmíněnou owssvr.dll knihovnou, tedy o data dynamická, a do výčtu typů souborů tedy musíte přidat DLL, namísto DOC apod. V tom případě však ještě pečlivěji sledujte procesorovou zátěž a rovněž mrkněte sem: http://support.microsoft.com/?id=841120

Kompresní stupeň

Ve výchozím nastavení je kompresní stupeň u statického obsahu nastaven na 10. V předchozích řádcích jsme si však již objasnili, že u statického obsahu se zvýšení procesorové zátěže, zejména tedy u SharePoint portálů, standardně obávat příliš nemusíme.

Ve výchozím nastavení je kompresní stupeň u dynamického obsahu nastaven na 0. Maximální hodnota je, podobně jako u statického obsahu, 10. 0 znamená bez komprese, 10 je komprese maximální, ovšem zároveň s největší procesorovou zátěží. Obecně je doporučováno u dynamického obsahu používat kompresní stupně od 4 do 7. Dobré je rovněž poznamenat, že mezi stupni 9 a 10 je jen minimální rozdíl ve velikosti přenášených dat, nicméně znatelný rozdíl v procesorové zátěži. Na stupeň 10 tedy zapomeňte rovnou a hlavně sledujte čítače procesorové zátěže. Kompresní stupeň lze u dynamického obsahu nastavit např. takto:
 

HTTP komprese a IIS 6.0 a IIS 7.0

HTTP komprese se drobně odlišuje mezi IIS 6.0 (Windows Server 2003) a IIS 7.0 (Windows Server 2008).

U IIS 6.0 se HTTP komprese nastavuje pro typy souborů dle jejich přípon, zatímco v IIS 7.0 se komprese nastavuje s využitím MIME typů. IIS 7.0 rovněž přichází s dalšími novinkami, jako je schopnost dynamického zapínání či vypínání komprese v závislosti na využití procesoru.
 

Příklad skriptu na zapnutí komprese pro IIS 6.0:

cd c:\inetpub\adminscripts
 

REM Zapnuti globalni komprese pro dynamicky a staticky obsah
cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoDynamicCompression true
cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoStaticCompression true
 

REM Nastaveni kompresniho stupne komprese dynamickeho obsahu
cscript.exe adsutil.vbs set w3svc/filters/compression/gzip/hcdynamiccompressionlevel "7" 
cscript.exe adsutil.vbs set w3svc/filters/compression/deflate/hcdynamiccompressionlevel "7"
 

REM Urceni typu souboru
cscript.exe adsutil.vbs set w3svc/filters/compression/gzip/hcscriptfileextensions "css" "js" "asp" "exe" "axd" "aspx" "ascx" "ashx" "asmx" "xml"
cscript.exe adsutil.vbs set w3svc/filters/compression/deflate/hcscriptfileextensions"css" "js" "asp" "exe" "axd" "aspx" "ascx" "ashx" "asmx" "xml"
 

iisreset 
pause

Příklad nastavení komprese pro IIS 7.0:

Nejprve do IIS 7.0 přidejte pomocí Server Manager konzole roli “Dynamic Content Compression”.

V IIS 7.0 je ve výchozím nastavení komprese statického obsahu zapnuta a komprese dynamického obsahu je vypnuta. Zapneme ji tedy takto:

APPCMD.EXE set config -section:urlCompression /doDynamicCompression:true

Dále nastavíme stupeň komprese:

APPCMD.EXE set config -section:httpCompression -[name='gzip'].staticCompressionLevel:9 -[name='gzip'].dynamicCompressionLevel:7

A následně určíme kdy bude komprese využívána vzhledem k aktuální procesorové zátěži (zde kompresi povolujeme při procesorové zátěži v rozsahu 20-75%):


 

APPCMD.EXE set config –section:httpCompression /dynamicCompressionDisableCpuUsage:75
APPCMD.EXE set config –section:httpCompression /dynamicCompressionEnableCpuUsage:20

Ukázka z praxe

Velikost přenášených dat souboru core.js je při použití komprese zmenšena z 266 KB na 59 KB.

komprese%2001[1] komprese%2002[1] komprese%2003[1]

Odkazy na závěr