rarouš.weblog

Náš intranet používá pro AJAXy ADO.NET Data Services, což je pěkný REST framework. Tento framework je postavený nad IQueryable (tedy LINQ) a také nad WCF. Nedávno jsme prováděli přeinstalace serverů a tak se stalo, že AJAXové dotazy začaly vracet 404.

Bylo to divné, protože jinde to fungovalo a vždy stačil xcopy deployment. Tak jsem zkusil zadat adresu služby do prohlížeče a zase 404. Proč to nejde? Koukám na mapování handlerů v konfiguraci IIS7 a helemese chybí svc binding. Ale proč? Vždyť je všechno nainstalovaný jak má bejt.

Po chvilce pátrání jsme našel jednoduché řešení. Stačí spustit registraci ručně:

"%systemroot%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe –i"

Pro 64-bitové systémy pak:

"%systemroot%\Microsoft.NET\Framework64\v3.0\Windows Communication Foundation\ServiceModelReg.exe –i"

Dnes mi píše Radek, že přesouval intranet na Domain Controller, aby nebyl na našich vývojových strojích a že mu AJAXy vracej 404. Takže tohle je i tak trochu pro něj.

Jedním z velkých problémů dnešních vyhledávačů je duplicitní obsah. Musejí se poprat s velkým množstvím stránek, které vypadají na první pohled shodně a liší se pouze v URL adrese. Jak mají rozhodnout, kterou z těchto adres vrátit uživateli jako jedinou správnou?

Problém duplicitního obsahu

Duplicitní obsah může vzniknout velice jednoduše, nemusí ani dojít ke zkopírování stránky někým jiným. Prostě stačí mít blbě nastavený server a vracet stejný obsah pro URL s i bez www. na začátku. Další možností je, že se vaše adresy dynamických stránek v čase vyvíjí. Začínal jsem s nepěknými adresami ve tvaru clanek.aspx?id=4, pak jsem časem přešel na SEO URL ve tvaru clanek.aspx/4-nejaky-nadpis, později jsem přidal URL rewriter a mé URL vypadaly takto clanek/4-nejaky-nadpis.aspx. Všechny tyto adresy vedou na stejný obsah, ale protože mají jinou URL, jsou to pro vyhledávacího robota různé stránky.

Jako správný poskytovatel obsahu bych měl zajistit, že všechny verze URL jsou stále funkční, ale měly by směřovat na jedinou platnou. Ale jak?

Řešení

Cest k cíli vede samozřejmě spousta. Pokud máte tu možnost, využijte nějaký URL rewriter. Zvolte si kanonickou formu vašich adres a tu všude používejte. Pokud nechcete používat v adresách prefix www., stačí málo.

Na IIS7 s URL Rewriterem přidejte do vašeho web.config souboru do sekce system.webServer/rewrite/rules následující kód:

<rule name="Remove WWW prefix" >
  <match url="(.*)" ignoreCase="true" />
  <conditions>
    <add input="{HTTP_HOST}" pattern="^www\.domain\.com" />
  </conditions>
  <action type="Redirect" url="http://domain.com/{R:1}" redirectType="Permanent" />
</rule>

Na Apachi stačí do souboru .htaccess přidat následující řádky:

# Remove WWW prefix
RewriteCond %HTTP_HOST ^www\.domain\.com [I]
RewriteRule ^/(.*) http://domain.com/$1 [RP]

Co ale dělat, pokud nemáte na serveru možnost URL rewriting provádět?

Naštěstí existuje alternativa. Vývojáři Google, Yahoo a Live Search se domluvili na zavedení link tagu, který určuje kanonickou URL přímo v dokumentu. Do sekce html/head vašich stránek přidejte následující tag:

<link rel="canonical" href="http://domain.com/kanonicka/adresa-stranky" />

Tím dosáhnete toho, že pokud crawler navštíví vaši stránku přes různé adresy, vždy ji bude považovat za jednu a tu samou s adresou, která je hodnotou atributu href.

Výkon webových stránek můžeme obecně zvýšit snížením počtu dotazů na server, snížením objemu přenášených dat, optimalizacemi HTML kódu a v neposlední řadě optimalizací výkonného kódu aplikace. První tři pravidla lze uplatnit i na obyčejných prezentacích, proto se na ně podíváme blížeji.

Snížení počtu dotazů na server

Prvním krokem v optimalizaci by mělo být snížení počtu dotazů na server. Čím víc dotazů, tím více se musí přenášet dat, tím více musí server vynaložit prostředků na jejich obsloužení.

Snažte se snížit počet souborů, které vaše stránka tahá s sebou. Pokuste se sloučit externí skripty do jednoho souboru, stejně tak stylopisy. Místo toho, abyste měli zvláštní stylopis pro tisk, využijte pravidla @media print. Dále omezte @import pravidla na minimum. Další spoustu dotazů mají jistě na svědomí obrázky. Využijte chytře techniku spojování obrázků a snižte tak počet dotazů na minimum.

Dalším krokem ke snížení počtu dotazů je správně nastavené kešování. Většinou se setkávám s tím, že kešování není řízeno vůbec nebo je rovnou zakázáno. To považuju za velikou chybu. Místo zakázání kešování, zkuste nastavit cache na minutu, dvě. Nedělejte to však pomocí meta tagů, to nemá žádný význam. Posílejte HTTP hlavičky. Např. Cache-Control: public, must-revalidate, proxy-revalidate, max-age=120 nastavuje veřejné kešování na dvě minuty a za tuto dobu musí jak lokální, tak proxy cache stránku obnovit.

Dalším účinným pomocníkem je Entity Tag – ETag. ETag je hash obsahu. Pokud se obsah změní, změní se i hash. Tento hash je posílán v hlavičce klientovi a ten ho může připojit do opětovného dotazu. Pokud se obsah na serveru nezměnil, server odpoví kódem 304 Not Modified. V takovém případě je odpověď krátká a přenáší se jen několik bajtů a klient ví, že může použít lokální verzi.

Správným nastavením hlaviček Cache-Control a ETag můžete svému serveru hodně odlehčit.

Snížení objemu přenášených dat

Když už máme snížený počet dotazů – tedy zátěž serveru, ve druhém kroku bychom se měli pokusit snížit trafic – množství přenášených dat. Zkoušel jsem několik technik. Rád používám XHTML protože ho pak můžu zpracovávat pomocí obecného XML readeru. A XHTML vyžaduje oproti HTML o dost bajtů navíc. Proto jsem si udělal takový malý benchmark mojí titulní stránky. Rozdíl mezi HTML a XHTML verzí je cca 3 %. Pak jsem zkusil ořezat přebytečné bílé znaky. Tam už to bylo o něco lepší úspora 13 %. Kombinace HTML bez bílých znaků pak je na šestnácti 16%. Je to sice pěkné číslo, ale zase taková úspora to není.

Proto jsem nasadil kompresi. Ta konečně přinesla kýžený výsledek – úspora 64 %. Docela zajímavý nástroj, který vám zjistí, zda kompresi používáte a kolik byste byli schopní uspořit, najdete na stránkách www.aspnetresources.com. Zkoušel jsem pokusně české portály a kompresi používá pouze Seznam.cz. Přitom zcela jistě ji dříve používal i Atlas.cz, nechápu, proč už není zapnutá.

Jak zprovoznit kompresi na vašem serveru? Pokud máte IIS 6 a možnost nastavit si server sám, tak detaily najdete v článku Enabling HTTP Compression (IIS 6.0), v případě IIS 7 zase v článku Changes to compression in IIS7. Pokud k nastavení serveru přístup nemáte, můžete použít HttpModul pro kompresi. Uživatelé Apache jistě znají mod_deflate a mod_gzip.

Správně nastavenou kompresí ušetříte trafik. Ať už platíte vy nebo váš poskytovatel, je nejen ekonomické ale i solidární mít kompresi zapnutou.

Optimalizace kódu stránky

Správně napsaným kódem se dá zrychlit vykreslování stránky.

• Pokud je vaše stránka well-formed a je validní, může být její vykreslení mnohem rychlejší.
• Pokud nastavíte obrázkům rozměry, bude vykreslování stránky plynulejší a nebude se nepříjemně natahovat.
• Pokud u dlouhých tabulek správně použijete thead, tfoot a vícero tbody, taktéž docílíte rychlejšího zpracování stránky.
• Pokud externí skripty a jiné větší objekty, na jejichž zpracování musí prohlížeč čekat, připojíte až na konec stránky, nebude se na ně zbytečně čekat na začátku nebo uprostřed. Je to třeba častý nešvar magazínů, kde se vám načte perex, pod ním se 20 sekund načítá reklama a pak najednou nablikne zbytek stránky.

Spoustu zajímavých tipů na zrychlení najdete ve vývojářské části Yahoo v článku Best Practices for Speeding Up Your Web Site. Užitečný nástroj ze stejné dílny, který vám stránku zkontroluje přímo ve vašem prohlížeči je Add-on do Firebugu s názvem Y-Slow.

Mnoho z vás si jistě řekně, „k čemu bych měl optimalizovat, když moje stránky navštěvuje pár lidí denně?“ Já jsem toho názoru, že plýtvat se nemá. Doma taky určitě nemáte neustále otevřený vodovodní kohoutek…

Možná už jste přešli na Vistu, nebo o tom přemýšlíte, a chtěli byste si zprovoznit PHP. Samozřejmě je tu možnost použít bundle s Apachem (neověřeno), ale tento článek bude o tom, jak to udělat na IIS 7.

Upozornění: Následující postup vám nebude fungovat na Home Basic edici Windows Vista, protože její součástí je pouze omezené IIS pro provoz WCF.

Microsoft a Zend nedávno podepsali dohodu o vzájemné podpoře, výsledkem je nový FastCGI modul pro IIS, na kterém by mělo PHP běžet stejně, ne-li lépe než na Apache. Na druhou stranu je tu podpora MS SQL pro PHP. Takže první plody tu máme a myslím, že k oboustranné spokojenosti.

Instalace IIS

Pokud ještě nemáte na Vistě IIS nainstalované, je tu vhodná chvíle to napravit. Otevřete si Control panel \ Programs a v sekci Program and Features klikněte na Turn Windows features on or off. Otevře se vám následující okno, kde zaškrtnete podporu CGI (není od věci si zapnout i ASP.NET, když už jsme tady).

Pokud chcete konzolu pro správu IIS najdete ji ve Web Management Tools, je tam jak stará šestková, tak nová sedmičková. Ale pro náši potřebu není bezpodmínečně nut­ná.

Po odkliknutí tlačítka OK budete pravděpodobně vyzváni k restartu systému.

Instalace PHP

Pokud tedy máme IIS nainstalováno, přejdeme k instalaci PHP.

1. Stáhněte si zip balíček Non-thread-safe Win32 binaries.
2. Balíček rozbalte např. do C:\PHP.
3. Přejmenujte soubor php.ini-recommended na php.ini.
4. Upravte následující klíče:
   • register_long_arrays = on
   • extension_dir = "C:\PHP\ext"
5. Soubor uložte.

Instalace FastCGI

FastCGI je novinkou IIS7, ale není ještě ve Vistě (bude až v 2008 Serveru a možná i v Service Packu pro Vistu, který by měl vyjít současně se serverem), proto je nutné ho doinstalovat.

1. Stáhněte si zip balíček pro x86 nebo x64 podle toho na jaké jste platformě.
2. Rozblate ho např. do C:\PHP\FastCGI\
3. Otevřete si příkazovou řádku (Win+“cmd“).
4. Pokračujte následovně:

C:\Users\rarous\Downloads>cd c:\php\fastcgi

c:\php\FastCGI>fcgisetup /install
Stopping IIS services ...
Copied files
Registered FastCGI configuration section
Installed FastCGI module
Starting IIS services ...
Success: Installation completed succesfully

c:\php\FastCGI>fcgisetup /add c:\php\php-cgi.exe PHP
Configured FastCGI pool
Created handler mappings
Success: Installation completed succesfully

Tím by mělo být hotovo. Pro ověření funkčnosti si vytvořte v c:\inetpub\wwwroot\ soubor index.php do kterého zadáte následující kód:

<?php phpinfo(); ?>

Uložíte a do browseru zadáte adresu http://localhost/index.php. Měla by se objevit standardní stránka s výpisem konfigurace PHP. Pro dnešek vše :)

PS. FastCGI se dá doinstalovat i do IIS 6 na Windows 2003.