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:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "7"
• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "7"

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:

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%):

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.

Odkazy na závěr

• HTTP komprese v IIS 6.0: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx?mfr=true
• Optimizing WCM Pefrormance: http://msdn.microsoft.com/en-us/library/bb727371.aspx
• Measuring the Performance Effects of Dynamic Compression in IIS 7.0 - http://www.webperformanceinc.com/library/reports/iis7_compression/
• HTTP Compression Analysis for BluedogLimited.com - http://www.bluedoglimited.com/SharePointThoughts/Documents/HTTP%20Compression%20Analysis.mht
• IIS 7 Compression. Good? Bad? How much? - http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx
• Výsledky nastavené komprese si můžete v praxi ověřit např. volně dostupným nástrojem Fiddler.

V poslední době dostávám stále více otázek týkajících se nové připravované verze SharePoint server, tedy SharePoint Server 2010. Mnoho informací oficiálně dostupných není a některé další, které jako MVP mám, zatím nelze zveřejnit, nicméně něco se pustit do světa již může. Odmítám však zveřejňovat spekulace, co zde píšu, není výmysl.

Co víme jistě:

1. SharePoint Server 2010 bude jen 64 bitový.
2. SharePoint Server 2010 bude vyžadovat 64 bitový Windows Server 2008, nebo 64 bitový Windows Server 2008 R2.
3. SharePoint Server 2010 bude vyžadovat 64 bitový SQL Server 2008 nebo 64 bitový SQL Server 2005.
   Jinými slovy – hodláte-li v dohledné době nasazovat SharePoint Server 2007, pak již rovnou na Windows Server 2008 a SQL Server 2008, vše 64 bitové. Jinak bude s upgradem zbytečně další práce navíc. Mimochodem – v SP2 je obsažena aktualizace STSADM, konkrétně “–o preupgradecheck”, což by před upgradem rozhodně nemělo uniknout vaší pozornosti.
4. SharePoint Server 2010 bude nově obsahovat PerformancePoint Services, tedy monitorovací a plánovací část PerformancePoint Serveru 2007, což je produkt, který od SP3 nebude dále samostatně vyvíjen. PerformancePoint Services budou v SharePoint Serveru 2010 dostupné pro zákazníky v rámci SharePoint Enterprise CAL licencí.
5. SharePoint v4 přinese zlepšenou podporu pro prohlížeče Firefox 3.x a Safari 3.x. Podpora pro IE 6.0 skončí v červenci 2010. Nový SharePoint s IE 6.0 nebude zcela kamarádit.
6. Dočkáme se i SharePoint Workspace 2010. Co to je? Nástupce aplikace Groove 2007 přeměněný do plnohodnotného offline SharePoint klienta se synchronizováním obsahu SharePoint seznamů. SharePoint Workspace 2010 bude nově obsažen i v edici Microsoft Office Professional Plus 2010.
7. Uživatelské rozhranní více ve stylu Ribbonu, ala Office 2007.

Co víme jen mlhavě:

• Datum uvedení produktu na trh stále neznáme, předpokládá se jaro 2010 (spolu s Office 2010)
• Nově budeme mít Database Attach Upgrade, viz. http://support.microsoft.com/kb/956448/en-us
• Pozor na opravdu velké seznamy (více než 2000 položek), po upgradu můžete pocítit výkonové problémy, viz. http://support.microsoft.com/kb/956201/en-us. No, snad ale bude konečně bez problémů funkční FileStream. Schopnost mapování seznamů k jejich vlastním DB tabulkám však bude cool.

Informace budu dále doplňovat tak, jak to bude možné. Každopádně – nový SharePoint v kombinaci s novými Office aplikacemi bude stát za to, konečně bude umět řadu věcí, které jsme chtěli již dávno. takže se máme na co těšit.