Hostujeme PHP aplikace na Windows (namísto Linuxu)

Naprostá většina webových programátorů v PHP / MySQL hostuje své aplikace na Linuxu, využívajíce LAMP platformu, nicméně vytvářejí je většinou na Windows. Řada z nich si nedokáže představit jiný postup. Tento článek by měl popsat výhody a nevýhody Windows hostingu pro PHP aplikace a zkušenosti s migrací aplikací mezi Apache -> IIS a MySQL -> SQL Server 2008.

Windows hosting versus Linux hosting (pro PHP)

Přestože osobně také preferuji na desktopu Windows (a aplikace pro ně), pro hostování PHP / MySQL aplikací jsem řadu let používal jen a pouze Linuxové webhostingy. Od spousty lidí nakonec stále není problém slyšet "axiom" na server patří Linux (aniž ovšem dodávají proč), a o Windows webhostingu vůbec neuvažují.

Výhody Windows 2008 Server hostingu

K přechodu na Windows hosting vás může přimět:

• potřeba využívat i jiné databáze než MySQL, například Microsoft SQL Server 2008, které mají lepší možnosti programování,
• potřeba provozovat současně PHP i ASP.NET aplikace na jednom serveru,
• pokud chcete hostovat větší množství domén, a vyplatí se vám tedy fyzický či virtualizovaný vlastní server, ale je pro vás (jako pro většinu lidí programujících na Windows) snazší administrovat si Windows 2008 Server než třeba Gentoo Linux,
• výrazná nespokojenost (podpořená zkušeností) s low-cost LAMP hostingy s "neomezeným" počtem domén, které se sice tváří jako ve všem nelimitované, ale v důsledku vás stojí spoustu nervů a zbytečného úsilí,
• potřeba ovlivnit nastavení serveru, které sdílená LAMP platforma nenabídne,
• snadná správa serveru i aplikací z Windows desktopu i mobilního telefonu,
• používání aplikací, které znáte z desktopu (správce souborů, editor, atd.), i pro práci na serveru,
• stabilní systém a "nezbořené" MySQL tabulky, jak je známe snad ze všech sdílených LAMP webhostingů.

Pokud tedy programujete na Windows (ať už jsou to XP, Vista či Windows 7), bude pro vás zřejmě přijatelnější tato administrace vlastního serveru než SSH příkazová řádka GNU Linuxu:

V případě Windows hostingu máte díky virtualizační technologii Hyper-V Microsoftu na výběr nejen relativně drahé fyzické servery, ale podobně jako na Linuxu i virtuální servery. Jedná o přidělení fyzické části RAM, výpočetního času procesoru a prostoru na disku vašemu virtualizovanému "stroji", který se následně tváří jako fyzický stroj a můžete tedy jeho nastavení 100% ovlivnit.

Současná tržní cena Hyper-V virtualizovaného serveru (VPS) v ČR s přiděleným 1GB RAM, 50GB diskového prostoru, neomezeného přesnosu v rámci NIXu, a s licencí na Windows 2008 Server  Standard je kolem 1000 Kč plus DPH měsíčně. Takovéto VPS webhostingové programy nabízí ASPone, Active24, Czechia, Forpsi,  a další. V této ceně se nejedná typicky o "managed" servery, je tedy nutné je aktivně administrovat - sledovat bezpečnostní problémy, logy, nechat pravidelně instalovat bezpečnostní aktualizace, nastavit korektně firewall, aktualizovat PHP - to je práce pro vás.

Vzhledem k tomu, že na VPS server můžete nasadit desítky vlastních domén či domén klientů, jedná se o rozumnou částku, která je ve finále nižší než platit třeba 20 x 150 Kč na běžném českém "LAMP webhostingu" účtujícím každou doménu zvlášť.

Nezanedbatelnou výhodou může být i snadná administrace serveru odkudkoliv pomocí Remote Desktop Mobile na telefonech s Windows Mobile (je to použitelné i při GPRS rychlostech):

Nevýhody Windows 2008 Server hostingu

Hlavní nevýhody Windows hostingu pro provozování stávajících PHP aplikací jsou tyto:

• část autorů PHP skriptů s hostováním na Windows vůbec nepočítá - například skoro žádná aplikace neumí pracovat s $_SERVER["UNENCODED_URL"], což je proměnná obsahující URL před jeho změnou pomocí Microsoftí verze "mod rewrite" na IIS7, část aplikací funguje beze změn jen pod Apache - v distribuci většiny open-source PHP aplikací naleznete jen .htaccess (pro Apache 2.x) namísto ekvivalentního web.config pro IIS 7.x,
• některé aplikace se spoléhají na postarší FilesMatch (namísto mod_rewrite) v .htaccess, a ty budete muset upravit,
• část samotných rozšíření pro PHP sice jde zkompilovat jako DLL pro Windows, ale nikdo z jejich autorů je takto pořádně netestoval a většinou nejsou stabilní (zatímco na Linuxu ano).

Obecně, pokud se jedná o vaše PHP skripty, nový vývoj nebo několik málo existujících open-source skriptů, bude většinou snadné tyto případné nekompatibility odstranit, pokud ale pracujete s velkým množství různých open-source skriptů, a nechcete každý jednotlivě testovat, bude pro vás snazší zůstat na LAMP platformě.

Část z těchto problémů samozřejmě řeší instalace Apache i na Windows 2008 jako webového serveru (namísto IIS), ale tím přijdete o možnost hostování ASP.NET aplikací.

Druhá (a lepší) možnost je mít v uvedených 1GB přidělené paměti VPS serveru spuštěn jak Apache, tak IIS7, MySQL i SQL Server 2008 Express (většina webhostingů nabízí 2 či více IP adres pro jeden VPS). Tím se dá snadno pokrýt přechodné období a migrace skriptů z Apache na IIS dostane rozumnější harmonogram.

Praktické zkušenosti z migrace LAMP -> Windows

Při přesunu webů z LAMP platformy na Windows 2008 Server s IIS (a bez Apache) jsem migroval aplikace založené na 7 různých platformách - BLOG:CMS, F-ART:CMS, PunBB fórum, IP.Board, Mantis BugTracker, Singapore Photo Gallery a Dokuwiki. Otestování kompatibility a nutné programové úpravy v PHP kódu byly v tomto případě otázkou zhruba 10 hodin práce.

Složitější bylo vybrat tu správnou PHP distribuci a zvláště akcelerátor, o tom ale níže.

PHP aplikace na Windows 2008 Server / IIS7

Instalace IIS

Prvním krokem pro migraci aplikací z Linux/Apache na /img/hosting/IIS je samozřejmě instalace vlastního webového serveru. IIS 7.0 je přítomen ve Windows Vista a Windows 2008 Server, IIS 7.5 ve Windows 7 a Windows 2008 Server R2. Instalace znamená spustit si volbu "Zapnout nebo vypnout funkce systému Windows" a zde si zvolit Internetovou informační službu a k ní patičné funkce, včetně CGI (což nainstaluje i potřebné FastCGI):

URL Rewrite

Následně je potřeba stáhnout si a instalovat podporu pro "mod rewrite", jak jej známe z Apache. Zde existují dva moduly, jeden zdarma pod názvem URL Rewrite Module nabízí přímo Microsoft, druhý je dostupný komerčně (US$ 99 na server) od společnosti Helicon Tech, pod názvem ISAPI/REWRITE/3.

Oba moduly mají své výhody a nevýhody - Microsoftí modul pracuje vždy s konfiguračním souborem IIS 7 serveru pro daný web, tedy web.config, ale umí jednorázově importovat do tohoto souboru většinu pravidel obsažených ve stávajícím .htaccess souboru z konfigurace pro Apache mod_rewrite modul.

Takovýto zápis souboru .htaccess (z Nette PHP frameworku):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$ index.php [L]

Převede importní filtr URL Rewrite Module na ekvivalentní zápis ve web.config:

<rule name="Nette rewrite" stopProcessing="true">
 <match url="\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$" negate="true" ignoreCase="false" />
 <conditions logicalGrouping="MatchAll">
  <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" pattern="" ignoreCase="false" />
  <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" pattern="" ignoreCase="false" />
 </conditions>
 <action type="Rewrite" url="/index.php" />
</rule>

ISAPI/REWRITE/3 se chová jinak - umožňuje IIS zpracovávat běžné soubory .htaccess z Apache. Nemusíte je nijak upravovat, postačí aplikaci nakopírovat do adresáře inetpub a prostě spustit, drtivá většina pravidel je kompatibilní (viz tato tabulka) a zpracovávána.

Oba dva moduly pro rewrite URL se chovají trochu odlišně ve spolupráci s PHP. Microsoftí URL Rewrite modul dává URL před jeho přepisem do proměnné $_SERVER["UNENCODED_URL"], zatímco modul od Helicon Tech do $_SERVER["HTTP_X_REWRITE_URL"].  Oproti Apache mod_rewrite může být také vhodné provést změnu {SCRIPT_NAME} za {URL}.

Osobně bych doporučil používat jen Microsoftí URL Rewrite modul a .htaccess pravidla importovat.

Instalace PHP

PHP se v IIS zásadně provozuje pod FastCGI rozhraním, nikoliv ISAPI. Je to nejrychlejší a Microsoftem podporovaná varianta. Toto rozhraní zajišťuje thread-safe prostředí, takže si můžete stáhnout z PHP.net non-thread-safe verzi PHP (je rychlejší než TS verze). Ideální je přitom PHP verze 5.3 (a vyšší), je totiž konečně nativně zkompilována ve Visual Studiu 2008 (VC9), zatímco PHP 5.2 a starší oficiálně podporovalo jen Visual C++ 6.0 z roku 1998.

Pro vývoj si ovšem nestahujte binární soubory PHP z PHP.net, na Windows existuje výkonově výrazně lepší řešení - komerční Zend Server, popřípadě jeho zdarma dostupná alternativa Zend Server Community Edition (CE).

Zend Server CE obsahuje kromě běžných rozšíření PHP i další zcela zásadní komponenty -  Zend Debugger, Zend DataCache a Zend Optimizer+. Zend Optimizer+ je rozšíření, které provádí kompilaci zdrojového PHP kódu do bytecode a také optimalizaci kódu, a tento opcode poté drží v paměti, což v praxi znamená několikanásobné zrychlení vaší aplikace.

Microsoft navíc úzce spolupracuje se Zendem, takže jeho řešení je nejen rychlé, ale i stabilní, otestované a na Windows de-facto jediné doporučitelné pro produkci.

Testoval jsem i další "PHP akcelerátory" (+ binární soubory z PHP.net) na Windows, ale ať už se jednalo o eAccelerator, XCache či APC, vždy byl dlouhodobý výsledek jediný - nestabilita. Tyto rozšíření lze zkompilovat pro Windows, ale nikdo je zjevně ve Windows pořádně netestoval a při zátěži nefungují.

V praxi tedy potřebujete zdarma dostupný Zend Server CE, a to ve verzi s PHP 5.3. Samotná instalace Zend Serveru je "klikací" a provede i veškeré potřebné úpravy v konfigurace IIS pro podporu PHP. Jediné, co budete muset doplnit je přidat nový typ pro "Výchozí dokument" - index.php a doladit php.ini.

Drobný problém Zend Serveru je snad jen to, že je kompilován pomocí Visual Studio 2005 (VC8), zatímco většina externích PHP rozšíření (DLL) je kompilována pomocí starého VC6 nebo naopak nového VC9. Jedná se třeba o SQLSRV driver pro PHP, tedy nativní ovladač od Microsoftu pro přístup k SQL Serveru 2008. Není ovšem problém si toto rozšíření zkompilovat i pod VC8, tento článek ukazuje jak.

Migrace databáze: MySQL -> SQL Server 2008

MySQL databáze pro Windows existuje a funguje dobře. V praxi jsem se za 6 měsíců provozu 10 webů s IIS 7 / MySQL 5.1 na Windows hostingu nesetkal s jediným problémem (použité jsou MyISAM i InnoDB tabulky), zatímco na různých sdílených webhosting serverech bylo poškození zejména MyISAM tabulek či indexů na týdenním pořádku.

Zvolený Windows hosting ovšem dává výbornou příležitost začít používat lepší databázové enginy než je MySQL - konkrétně SQL Server 2008. Ten je ve verzi SQL Server 2008 Express with Advanced Services dostupný zdarma, a to i pro komerčí použití (je ovšem omezen na využití max 1GB RAM a 4GB velikosti databáze, viz srovnání edicí). SQL Server 2008 je databáze, která výborně škáluje, je stabilní a je možné ji programovat podstatně lépe než MySQL. Výborné jsou i nástroje pro ladění výkonu - SQL Server Profiler a Database Engine Tuning Advisor. Pro správu databáze i vývoj je zdarma dostupná aplikace SQL Server Management Studio.

Pro propojení SQL Serveru 2008 s PHP existuje řada starých, pomalých a neaktualizovaných rozšíření integrovaných ve standardní verzi PHP (jmenovitě MSSQL, PDO_MSSQL a ODBC), a poté funkční, rychlý a aktualizovaný SQL Server driver 1.1 for PHP, což je relativní novinka od Microsoftu publikovaná na Codeplexu v open-source licenci. Pro použití se Zend Server CE si jej budete muset zkompilovat pomocí VC8, anebo stáhnout binárku zde (Microsoft dodává jen VC6 a VC9 binární soubory).

Tento driver zavádí do PHP nové sqlsrv funce, jejichž dokumentace je dostupná na MSDN. S SQL Serverem komunikuje od verze 1.1 přímo přes SQL Server 2008 Native Client, tedy tou nejrychlejší možnou cestou.

Při migraci databázového layeru vaší aplikace a jeho uzpůsobení z MySQL na SQL Server 2008 a sqlsrv funkce budete potřebovat znát minimálně následující rozdíly:

Neexistuje LIMIT start,offset

SQL Server 2008 nepodporuje v SQL SELECT dotazech stránkování, tedy LIMIT start, offset příkaz (podobně to nenabízí ani Oracle či Sybase), což se na webu přitom velice často používá. Podporuje jen ekvivalent LIMIT 0, offset a to ve formě SELECT TOP x. Nicméně není problém si napsat stránkování vlastní, a to za pomocí funkce ROW_COUNT(), která vrací číslo aktuálního řádku podle určeného řazení v OVER (ORDER BY ...).

V praxi je pro migraci z MySQL na SQL Server 2008 nejjednodušší napsat si funkci v databázovém layeru, která upraví původní SQL dotaz do vnořeného sub-SELECTU, v této formě:

SELECT queryresult.* FROM (
   SELECT fieldsX, 
   ROW_NUMBER() OVER (ORDER BY fieldsY) as rnumber
   FROM table
) as queryresult
WHERE queryresult.rnumber BETWEEN ($start+1) AND ($start+$offset)

S takovou funkcí můžete používat syntax MySQL dotazů, a pro SQL Server budou správně překládány pro stránkování.

Defaultně není použito buffered query a tím ani neznáme počet záznamů

MySQL databáze implicitně používá buffered query, což nejdříve přenese veškeré výsledky dotazu na klienta (PHP), a poté se dá použít funkce mysql_num_rows() pro jejich sečtení.

PHP driver pro SQL Server 2008 naproti tomu používá defaultně rychlejší unbuffered query (stejně jako třeba OCI8 rozhraní pro Oracle). Pokud v kódu potřebujete vědět předem počet řádků, doporučuji jej přepsat, většinou to totiž není nezbytně nutné, a často postačí jedna IF podmínka navíc, popřípadě můžete počítat počet řádků v průchodu WHILE cyklem pro FETCH, kdy počet znáte na konci cyklu.

Počítat dopředu počet položek bývá z 99% programátorská chyba. Většinou navíc ani nepotřebujete počet, spíše něco jako "has_rows()", tedy IF row count>0.

Pokud přesto počet položek dotazu potřebujete, tak driver 1.1 zavádí funkce sqlsrv_num_rows a sqlsrv_has_rows. Pro použití té první ovšem musíte daný SQL dotaz zadat s parametrem "Scrollable" => SQLSRV_CURSOR_KEYSET, tedy použít (oproti unbuffered query pomalejší) databázový kurzor. Alternativou je samozřejmě i použití SELECT COUNT(*) FROM.

Znaková sada a připojení k databázi

Datové typy nvarchar, ntext a další používají interně v SQL Serveru UCS2LE kódování. PHP Driver pro SQL Server takováto data poskytne defaultně v UTF16LE, pokud ale při připojení k databázi použijete parametr "CharacterSet" => "UTF-8", tak je převede z / na UTF-8 na vstupu i výstupu.

Připojení se k SQL Serveru 2008 s automatickou konverzí dat na UTF-8 může v PHP vypadat takto:

$SQL_HOST = 'localhost';
$SQL_PARAMS = array(
 'App' => 'aplikace',
 'ConnectionPooling' => true,
 'Database' => 'databaze',
 'UID' => 'uzivatel',
 'PWD' => 'heslo',
 "CharacterSet" => "UTF-8",
 'Encrypt' => false
);

$db = sqlsrv_connect($SQL_HOST, $SQL_PARAMS);
if (! is_resource($db)) die( 'Nemohu se pripojit k databazi');

 Číslo posledního vloženého záznamu s autoincrementem

Pole s automaticky se zvyšujícím sekvenčním číslem se nenazývá v SQL Serveru AUTOINCREMENT jako v MySQL, ale IDENTITY.  Jeho hodnotu změníte snadno v SQL pomocí příkazu dbcc checkident.

Na poslední hodnotu IDENTITY, kterou vygeneroval INSERT INTO, neexistuje speciální PHP funkce jako v MySQL - mysql_insert_id(), ale získáte ji tímto SQL dotazem:

SELECT SCOPE_IDENTITY() AS 'Identity'

Ladění při vývoji

Při vývoji je dobré si zapnout maximální úroveň logu, a to příkazem:

sqlsrv_configure("WarningsReturnAsErrors", true);
sqlsrv_configure(LogSeverity, SQLSRV_LOG_SEVERITY_ALL);

 Rychlost dotazů

Plánování dotazů funguje v SQL Serveru 2008 jinak než v MySQL, takže to chce věnovat pozornost zejména návrhu indexů a VIEWs. Výborné je, že v SQL Serveru 2008 máte dostupné kvalitní nástroje na monitorování a ladění.

Doporučuji mít při vývoji neustále zapnutý SQL Server Profiler, a případně se po nějaké době podívat i na doporučení od aplikace Database Engine Tuning Advisor. Tyto nástroje v SQL Server 2008 Web / Standard / Enterprise snadno zjistí zásadní problémy návrhu DB již při vývoji.

Není ale příliš dobré aplikovat hromadně doporučení Database Engine Tuning Advisor (mohou jich být stovky). Často je lepší dotaz přepsat a případně k němu vytvořit ručně indexy pro tabulky a podívat se na jejich Execution Plan v Microsoft SQL Server Management Studio.

Triggery používají "inserted" a "delete" temporary tabulky

SQL Server 2008 nemá BEFORE INSERT triggery jako třeba MySQL či Oracle. Řeší se to jinou logikou  - AFTER INSERT triggerem, který pracuje s pomocnými tabulkami inserted (či deleted), které mají stejnou strukturu jako tabulka, nad níž se trigger aktivoval, a obsahují vložené (či smazané) záznamy.

V triggeru můžete aktualizovat i samotnou tabulku, která trigger vyvolala, což při jiném přístupu nebývá pravidlem. Kurzory v T-SQL zde fungují podobně jako na Oracle v PL-SQL.

Malý příklad AFTER INSERT triggeru i s (poněkud zbytečným, ale zde jde primárně o ukázku) použitím kurzoru - po vložení komentáře se aktualizuje tabulka článků o statistiku počtu komentářů a datum poslední diskuze, ke komentáři se dá jeho pořadové číslo v rámci diskuze:

CREATE TRIGGER [dbo].[TR_comment_insert] 
   ON  [dbo].[comment] 
   AFTER INSERT
AS 
BEGIN
 SET NOCOUNT ON;
 DECLARE @citem as int, 
      @ctime as datetime, 
      @crel as int, 
      @cnumber as int;
 DECLARE item_cursor CURSOR FOR 
   SELECT citem, ctime, cnumber 
   FROM inserted ORDER BY ctime ASC, cnumber ASC;
 OPEN item_cursor;
 FETCH NEXT FROM item_cursor INTO @citem, @ctime, @cnumber;
 WHILE @@FETCH_STATUS = 0
  BEGIN
   UPDATE dbo.item SET 
     ilatestcomment = @ctime, 
     inumbercomments = inumbercomments+1 
   WHERE inumber=@citem;
   SELECT @crel = inumbercomments FROM dbo.item WHERE inumber=@citem;
   UPDATE dbo.comment SET crel=@crel WHERE cnumber=@cnumber;
   FETCH NEXT FROM item_cursor INTO @citem, @ctime, @cnumber;
 END
 CLOSE item_cursor;
 DEALLOCATE item_cursor;
END

CLUSTERED indexy na primární klíč nemusí být vždy vhodné

Dobře si rozmyslete, zda chcete PRIMARY indexy dělat jako CLUSTERED, což znamená, že  řazení v indexu je poté ovlivněno fyzických pořadím záznamů na disku, pokud jsou v tabulce milióny položek a vy drobně modifikujete jednu hodnotu, bude SQL Server provádět zbytečně mnoho IO operací.

Jedná se přitom o defaultní hodnotu pro primární klíč, pokud jej vytváříte pomocí SQL Server Management Studio.

Datetime typ nevrací varchar, ale DateTime objekt

Pokud máte v databázi datetime položku, v MySQL tato vrací při SELECTu datový typ string (a podobně se chová i SQLite), nicméně v SQL Serveru vám vrátí objekt typu DateTime, s nímž se dále dá pracovat v PHP třeba pomocí ->format() metody, viz dokumentace.

Pro práci s datem existuje v SQL Serveru velice komfortní funkce DATEADD, s prvním parametrem hour, day, month, atd., čímž můžete snadno nahradit funkce DAY(), MONTH() a další z MySQL.

Závěr

Tento článek představil základní body migrace aplikací z LAMP prostředí na kombinaci Windows 2008 Server + IIS 7.0 / 7.5 + Zend Server CE (PHP 5.3) + SQL Server 2008 + SQLSRV driver.

Osobně jsem s touto kombinací spokojen, protože mi po řadě let na Linuxu / Apache nabídla naprosto bezproblémový provoz, opravdu snadnou administraci serveru z Windows desktopu i telefonu, a nakonec i výraznou úsporu nákladů. Přesun části logiky z PHP do transakčního zpracování na úrovni databáze (Transact-SQL) zase znamenal 100% integritu dat a vyšší výkon aplikací (ano, jsem přesvědčen, že kritické zpracování dat se má odehrávat co nejblíže místu jejich uložení, tedy v databázi, a vždy transakčně).

Přestože většina lidí hostuje PHP aplikace na Linuxu / Apache, tak Windows 2008 Server / IIS7 se ukázal jako výborná platforma i pro PHP aplikace.