Názory k článku
Hostujeme PHP aplikace na Windows

Musím pochválit tento článek. Je věcný a upozorňuje na všechny možné problémy. Zmiňuje výhody i nevýhody případné migrace. Opravdu povedené.

PHP 5.3 by som do produkcneho prostredia este asi zatial nedaval.Osobne som s nim mal dost problemov.
Tak isto zend debugger a zend optimizer obcas blbnu.Co sa tyka optimizeru tak mam celkom dobre skusenosti s phpexpress od nusphere.
Trochu ma rozculuje aktualny stav okolo kompilatorov, v ktorom je to ktore PHPcko skompilovane.Je okolo toho docela chaos a bordel.

Pokud člověk nepoužívá kompilátory opkódu a debuggery na produkčním prostředí, tak mohu PHP 5.3 jednoznačně doporučit. (Tzn. místa typu intranety, drobné servery, ale na vysokozatížené servery stejně dopředu vše testujeme, že? :))

Podle informací z fór tyto optimalizátory doposud nefungují (k dnešnímu datu, webOptimizer, APC, …)

Co se týče kompilátorů a binárek pod Windows, nemyslím, že by v tom byl nějaký extra bordel. PHP <= 5.2 se kompilovalo pod VC6. PHP >= 5.3 se kompiluje pod Visual Studiem 6 i 9 (osobně mám zkušenosti s 9 pro 32bit, řádný problém). PHPeři k tomu napsali hezký skript, tutorial k vidění na http://wiki.php.net/…pbystepbuild , další info na http://cz2.php.net/…building.php . Knihovny z PECL je nutné zkompilovat ručně, adresa http://pecl4win.php.net/ mmnt. nefunguje.

PS: PHP 5.3 momentálně prý nejde na Windows zkompilovat jako ISAPI modul pod Apache2.2.

Jenom bych doplnil, že pokud plánujete pracovat s MSSQLí databází z PHP, stojí Vám za to to úsilí rozchodit Microsoft SQL Driver for PHP.

Pracuji s PHP s MSSQL už řadu let (původní knihovna funkcí mssql_*() z PHP), a chci Vás upozornit na spoustu omezení, které tato původní knihovna má a proč se vyplatí přejít na sqlsrv_*():
– jakkoliv dlouhá textová buňka byla oříznuta na délku 4kb – delší texty je nutné získávat po kouskách
- na UTF-8 bylo možno zapomenout (buď single-byte ve znakové stránce serveru, nebo UTF-16LE (ale pak je nutné ručně přepisovat query)
- problémy s datem – formátuje se dle locales serveru
- LIMIT … OFFSET … nejde (v MSSQL Serveru 2000 to nejde už vůbec, tam se to řeší pomocí subselectů). V nové knihovně alespoň můžete použít scrollable rowsety a vytřískat jenom část výsledku

a mssql_fetch uz rozlisuje 0 od NULL pre stlpce typu bit?

Díky za velmi zajímavý článek, spoustu lidí ani nenapadne, že se dá PHP na Windows pohodlně rozjet i na jiném serveru než na Apache.

Poznámka k tomu rozjetí IIS a Apache zároveň: Obvykle se to řeší tak, že se jeden ze serverů spustí na jiném portu než 80 a druhý mu dělá proxy. Respektive jako ta proxy se používá ještě další webserver, který je „tenký“ a rychlý, dnes asi nejčastěji nginx.

Co se týče snadné správy serveru, většina lidí, co si myslí že rozumí Windows, pořádně neumí ani spravovat svůj desktop, natož pak na Windows postavený server. Že má něco GUI ještě neznamená, že je to snadné. A i Linuxová (apod.) řešení mají mnoho různých grafických nástrojů pro správu. Například webové nástroje jako Webmin, Plesk, apod., které se dají snadno používat z jakéhokoliv mobilu s internetovým prohlížečem, kdy není třeba mít nadupaný telefon s RDP klientem. Ale znalost správy serveru v konzoli je základ, a to i Windows serverů!

Jen je škoda, že jsou ty Windowsové VPS tak drahé. Oproti Linuxovým, kde se dá pořídit VPS s 4GB RAM a 40GB HDD za 300Kč měsíčně (např. vpsFree.cz), je to podstatný rozdíl. A to se nebavíme o cenách za Microsoftí licence v případě pořízení vlastního serveru či několika serverů. Na to už dojela spousta nadějných projektů vytvořených v Express edicích .NET nástrojů. Náklady na provoz a použité technologie by si vývojáři měli rozmyslet dříve, než se pustí do vývoje. Každý by chtěl mít úspěšný web s miliony návštěvníků denně, ale pro takové weby nebude PHP na IIS vhodná volba. Ostatně ani PHP ne, ale to už je jiný příběh :-)

Windows hosting je zbytocne nakladny. S Linuxom je tiez menej prace, ak potrebujeme rozbehat nieco nestandardne (pretoze na Linuxe to uz niekto robil pred nami)

Pre spolahlivy webserver uplne staci virtualizovany Linux + normalna databaza ako Postgres.

Potom jedina vyhoda Windowsu je moznost vsetko si naklikat, ale myslim, ze spravcovia servrov nie su natolko neskuseni aby nezvladli prikazovy riadok.

Co sa tyka pohodlneho file managera, cez SSH sa daju velmi pohodlne spravovat subory.

Souhlas. Třeba instalace lamp treba na ubuntu se dá udělat jedním příkazem

sudo aptitude install apache2 php5 php5-mysql mysql-server

potom pár minut nastavení konfigurace, pokud výchozí nevyhovuje a je hotovo.

A kde to zmiňované „V článku si popíšeme výhody a nevýhody Windows hostingu pro PHP“

Bohužel je to napsané tak, že to zní, jako kdyby na tom virtuálním serveru musely běžet Windows, nicméně explicitně to tam (ve výpisu bodů, proč ne sdílený LAMP) nikde uvedené není

Kravaťáckými důvody je myšleno „naše firemní infrastruktura běží na windows, takže vámi vyvíjená aplikace musí běžet taky na windows“. Ten dává perfektní smysl a je většinou zbytečné kvůli neochotě se tomu přizpůsobit přijít o zakázku. Kupodivu jediný není uvedený.
Zbytek srovnává výhody virtuálního Windows serveru se sdíleným hostingem a úplně zapomíná, že Linuxový virtuální server je nejméně stejně tak dostupný. A pokud si někdo troufne na administraci Windows serveru pro PHP, tak je určitě dostatečně odvážný troufnout si na třeba Ubuntu LTS server (rozhodně ne Gentoo). Zkousnout příkazovou řádku považuju za mnohem jednodušší, než procházet všemi popsanými problémy.

Zajímavý článek obsahující plno podnětných a zajímavých informací, na druhou stranu – nikdy bych to nedělal (kdyby mne k tomu nedonutily okolnosti obchodního charakteru – klient má svůj Windows Server a na něm má běžet MySQL + PHP aplikace, která již existuje a běhá spolehlivě na Linuxu). Z článků jsem si odnesl sice mnoho zajímavých poznatků, vím nyní, že PHP a spol. na Windows běží (za jakou cenu). Ale i kdybych byl zapřísáhlý „okenář“, tak bych se rychleji a snáze naučil nastavit vše např. v Debianu, než klikat jak o život a řešit takové potíže – protože jak zde již někdo zmínil, kdo má čas, trpělivost a odvahu s tím bojovat ve Windows, tak už se rovnou může jako nezkušený pustit do konfigurace v Linuxu.

Hostovani na GNU/Linuxu je o pohodli, rychlosti, stabilite, komfortu a lepsich technologiich (Postgresql, PHP). Uvedene „problemy“ popsane v clanku jsou popisem, jak si nastavit to, co jinde (Linux) nastavovat nemusite.

Pokud se clovek stara o LAMP hosting, neresi zadne problemy :) I takova trivialita jako dobre si nastavit firewall neni totiz nutne v Linuxu delat (bezpecny OS bez zbytecnych sluzeb, ktere je treba FW blokovat). Vzdalena administrace Linuxu nema chybu, moznosti PostgreSQL jsou daleko pred MSSQL.

Ale Petře, já jsem nikde nenapsal, že je jednodušší to, co se dá naklikat. Já jsem napsal, že je to pohodlnější – což je někdy pro uživatele rozhodující (teď mluvím obecně, ne konkrétně k článku a jeho autorovi).

Proti tomu používat PHP na Win stojí zejména fakt, že PHP je komunitní projekt vyvíjený na Linux/Unixu. Core PHP vývojářů, kteří pracují na win je minimálně. A pokud chcete používat PECL extenze, jste téměř nahraní. Kompilovat si extenze na Win je mnohem obtížnější něž na Linuxu.

Jediný opravdový důvod k tomu použít PHP na Win je, pokud vaše PHP aplikace je na win prostředí nějakým způsobem závislá (většinou intranety). Pak by ovšem bylo na místě zvážit, zda to nepřepsat do .NETu.

Spíš by mě zajímalo, proč to MS dělá, možná v tom budou nějaké peníze od Zendu, smlouva, možná kvůli cloudu. Zájem MS je, aby jste to přepsali do .NETu, na rozvoji PHP žádný zájem nemá, naopak. Další věcí je, že nativním aplikacím pomalu a jistě u MS zvoní hrana, budoucnost Windows je .NET, nikoli WinAPI.

Jednoznačně .NET.

Tak říkáš, že mám něco o Javě sepsat? :-)

Svoje začátky s J2EE už pamatuji jen matně, je fakt, že dneska čerpám většinou z článků zaměřených na jedno konkrétní úzké téma, kdežto nějaký ucelený zdroj v češtině pro začátečníky chybí. Prostě takové „chci začít dělat weby v Javě, tak mi poraďte jak na to“. I když nějaký seriál tady na Rootu byl. Tak já si to přidám na svůj seznam úkolů a snad jednou… :-)

Tak to jsem vážně netušil :-D

Banky a další velké firmy hrají druhou až třetí ligu? Ty desítky nebo stovky webových J2EE frameworků, které vznikly právě kvůli webu a AJAXu, jsou „znásilněním“ a pro web se nehodí? Java jako jazyk tu sice byl dávno před webem, jak ho známe dnes, ale ty frameworky (včetně těch přímo od Sunu) vznikaly právě kvůli webu.

Dot NET z tohoto (webového) pohledu hodnotit moc nechci – mám zkušenost jen s pár mizernými a padajícími weby (ale i s nepadajícími) a k tvorbě webu v .NETu jsem jen přičuchnul (nijak mne to nezaujalo, Java je lepší).

Ale proti těm progresivním technologiím nic nemám. Jde prostě jen o to, co chceš, někdy se hodí ověřená a odladěná platforma pro kritické aplikace a jindy si chce člověk trochu zaexperimentovat a odvázat se :-)

P.S. co se týče začátečníků a výuky, má Java jednu velkou výhodu – jakž takž programátora vede k tomu, aby dal aplikaci nějakou architekturu, rozdělení na vrstvy, myslel na znovupoužitelnost – což jsou věci, ke kterým se člověk musí v mnoha jiných jazycích pracně nutit (ty ho vedou k opaku). No, zkusím sepsat nějaký ten návod :-) ale zítra to nebude…

Jednak jsou dost univerzální a jednak v té Javě píšeš aplikační logiku (tedy programování) a na tvorbu stránek (tedy dokumentů, prezentační vrstvy) používáš JSP nebo nějakou jeho nadstavbu – což je velmi vhodný přístup, programuješ v programovacím jazyce a dokumenty (HTML) vytváříš jako dokumenty, šablony (JSPX je XML, které má k (X)HTML velmi blízko).

Nechcete ten návod nabídnout na redakce@zdrojak.cz? Rád jej tu vydám…

OK, snad se k tomu v dohledné době dostanu :-)

Přijde mi, že sice to jde, ale je to dost pitomé řešení. Asi jako snaha běhat na Linuxu .NET aplikace přes Mono. Jakž-takž to funguje, ale primárně to bylo vyvíjeno na jinou platformu a je to znát. Neodladěné, s malou uživatelskou základnou, těžko řešitelné případné problémy, neustálý boj s tím, že vývojáři předpokládají specifika původní cílové platformy apod.

Článek mě jedině utvrdil v tom, že to tak doopravdy je. U autora byla navíc vidět obrovská snaha prosazovat Wokna nad Linuxem, která – ať už jím samým či následnou korekcí ze strany zadavatele – vyzněla v trapné srovnávaní jablek s hruškami. Konkrétně například:

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

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í

Opravdu netuším, jak může autor srovnávat VPS s Windows a low-cost LAMP hostingy. Férové srovnání by bylo VPS s Windows a VPS s Linuxem (pak by ale musel uvést, že Windows VPS bývají oproti Linuxovým VPS dražší a to i třeba o desítky procent). A samozřejmě srovnání low-cost Windows hostingů s low-cost LAPMy.

V bankovním sektoru se používají i Windows 3.11 a znamená to snad něco?

Ano, aplikace pro Mono fungují jakž takž, minimálně protože občas obsahují platform-specific záležitosti nebo věci v Monu dosud neimplementované. V době, kdy Microsoft má za sebou dávno release .NET 3.5 a venku je beta .NET 4.0, Mono se nachází někde kousek za .NET 2.0.

Takže mám dojem, že dobu zaspal někdo jiný (vývojáři Mona) a někdo další (Vy) se snaží tvářit, že se vlastně vůbec nic neděje.

Pokud chce někdo provozovat Apache i IIS na jednom serveru a nechce uživatele nutit specifikovat odlišný port (např. 80 pro IIS a 8080 pro Apache), může využít modul Application Request Routing (http://www.iis.net/…questRouting), který umožní IIS nastavit jako reverzní proxy pro Apache. (Nebo to jde udělat opačně – Apache může být reverzní proxy pro IIS s pomocí mod_proxy.)

Hodí se pro zprovoznění aplikací, které se bez Apache obejdou jen těžko, např. Trac.

Proc se Trac jen tezko oejde bez Apache? A jak je mozne, ze ho provozuji pod Lighttpd? Videl jste nekdy originalni dokumentaci? Pokud nevite, jak odpovedet na libovolnou z uvedene trojice otazek ci na ni odpovite zaporne, doporucuji Vam

http://trac.edgewall.org/…/TracInstall#…

Nemyslel jsem to tak, že by Trac jinde než na Apachi neběžel (to samozřejmě není pravda a taky jsem to nikde nenapsal), jen drtivá většina návodů běh na Apachi předpokládá. Pro člověka bez hlubších znalostí Tracu, což byl přesně můj případ, bylo prostě jednodušší využít IIS jako reverzní proxy. Tip byl pro lidi, co jsou na tom podobně.

Axiom (z řec. axióma, to co se uznává) je tvrzení, které se předem pokládá za platné a tudíž nedokazuje. ;)

ja mam ve svych windows mobile na HTC Touch HD normalne remote desktop aplikaci primo od M$. Funguje paradne, zejmena na 3G pripojeni (full grafika), na GPRS se musim smirit s nizsi kvalitou, ale porad to jaksi jde… Samozrejme Touch Pro 2 s klavesnici je s pouzitelnosti jeste o kus dal…

Ad „Výhody Windows 2008 Server hostingu“:
bohužel se tu směšují výhody/nevýhody související s přechodem od sdíleného hostingu na vlastní (virtuální) server a výhody/nevýhody přechodu z jedné platformy na jinou.

„potřeba využívat i jiné databáze než MySQL, například Microsoft SQL Server 2008, které mají lepší možnosti programování,“
Slova „i jiné“ by bylo vhodné vynechal. Stěhuje-li se člověk od MySQL za něčím „lepším“, např. Oraclem, DB/2, PostgreSQL… může zůstat na Linuxu, Solarisu nebo jiném unixovém OS. Důvod ke stěhování na Windows je tedy jen ten MS SQL Server → takže žádné „i jiné“.

„potřeba provozovat současně PHP i ASP.NET aplikace na jednom serveru“
Jsou tu sice i alternativy, jak provozovat .NET v Linuxu, ale netroufám si tvrdit, že jsou 100% plnohodnotné. Takže tenhle argument beru: kdo potřebuje ASP.NET, tomu není pomoci a holt ty Windows asi bude muset mít.

„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í s Windows) snazší administrovat si Windows 2008 Server než třeba Gentoo Linux,“
Nevím, proč je zde Linux zastoupen právě Gentoo. Proč ne třeba Debian/Ubuntu, které se spravují (alespoň pro začátečníka) snadněji. Existují webové administrační nástroje, jak pro apache, tak mysql, takže ta příkazová řádka nebude nutná.

„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í,“
To ano, mizerný hosting je k zlosti, zvlášť když na tom závisí váš byznys. Ale to je zase otázka sdílený vs. vlastní, případně kvalitní vs. mizerný, nikoli Linux vs. Windows.

„potřeba ovlivnit nastavení serveru, které sdílená LAMP platforma nenabídne,“
Opět ta samá písnička. „Sdílená LAMP“ platforma. Ona sdílená být nemusí, může být vyhrazená. Opět to tedy není problém Linux vs. Windows.

„snadná správa serveru i aplikací z Windows desktopu i mobilního telefonu,“
Pod snadností si každý představí něco jiného, takže je to dost subjektivní. Nicméně já bych dal přednost raději webovému administračnímu rozhraní (u LAMP) nebo SSHčku, se kterým se dá pracovat i v tom telefonu, než na malém displeji mobilu hledat nějaké ikonky na vzdálené RDP ploše. Ovšem je to věc vkusu. (Např. takový YAST (klikací GUI pro správu SUSE Linuxu) se dá spustit taky na dálku přes SSH).

„používání aplikací, které znáte z desktopu (správce souborů, editor, atd.) i pro práci na serveru,“
já jsem např. z desktopu zvyklý na jEdit a ten si taky můžu pustit na dálku přes SSH. Ovšem spíš bych si připojil serverový souborový systém pomocí SSHFS a editor si spustil lokálně. Nicméně tento postup příliš nedoporučuji, může totiž vést k nevhodným návykům. Místo seriózního stylu vývoje (vývoj a verzování → nasazení na testovací stroj → nasazení na produkční stroj) se pak někteří uživatelé uchylují k úpravám a programování přímo na produkčním serveru a doslova „bastlení“

„stabilní systém a „nezbořené“ MySQL tabulky, jak je známe snad ze všech sdílených LAMP webhostingů.“
A znovu: chyba hloupých adminů, chyba sdíleného hostingu (oproti vlastnímu serveru), případně chyba MySQL. Nejedná se o výhodu Windows hostingu. Na Linuxu lze se provozují i jiné databáze (PostgreSQL, Oracle…), existují schopní admini, existují nesdílené hostingy.

„než platit třeba 20×150 Kč na běžném českém „LAMP webhostingu“, účtujícím každou doménu zvlášť.“
To by bylo jistě hloupé. Nicméně stále to není důvod k přechodu na Windows – Linuxovou VPSku nebo vlastní linuxový server si snad nemůžu pořídit?

Vyplývá mi z toho, že windowsovský hosting buď výhody nemá, nebo je autor nezná, a tak si musel vymyslet tyto.

Ad „Nevýhody Windows 2008 Server hostingu“
Zde se dozvídáme, že některé PHP aplikace jsou zprasené. Ano, jsou, to mohu potvrdit, ale že by to byla nevýhoda Windows hostingu jako takového?
Skutečné nevýhody budou někde jinde…

Navíc je potřeba doplnit, že když už přecházíme z webhostingu na VPS či vlastní server (což autor směšuje s přechodem na Windows), máme daleko širší paletu, nemusíme se držet jen PHP a MySQL, můžeme si život zpříjemnit např. tím, že budeme psát v Javě a jako DB používat PostgreSQL (tato DB je i na mnoha hostinzích).

„Neexistuje LIMIT start,offset … (podobně to nenabízí ani Oracle či Sybase)“
Bohužel ano. Ovšem: co definuje SQL standard? Chvilka napětí … ano, je to právě zápis „LIMIT start, offset“.

„Pokud v kódu potřebujete vědět předem počet řádků, doporučuji jej přepsat“
Ano, takový kód by se skutečně přepsat měl – v ideálním případě aplikace funguje jako roura, čte záznamy z DB a vychází z ní výstup.
Přístup, kdy nejdřív natáhneme všechny záznamy z DB, pak něco uděláme a pak všechno najednou vyplivneme na výstup, není ideální,
i když to jinak nejde, neměli bychom ho používat, pokud to není nutné.

„$db = sqlsrv_connect“
Zajímalo by mne, proč autor používá tuto funkci pro přístup k MS SQL, když tu máme PDO, které tento DBMS také podporuje.
Když už si tedy hrajeme na nějakou přenositelnost mezi OS a mezi DBMS, měli bychom používat PDO nebo nějakou jinou vrstvu, která nás od konkrétní implementace databáze odstíní – jinak budeme ten kód přepisovat jako blbci pořád dokola.

„Přesun části logiky z PHP do transakčního zpracování na úrovni databáze (Transact-SQL) zase přinesl stoprocentní 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ě).“
S tím se dá souhlasit. Bohužel to ale opět není nic specifického pro Windows a MS SQL. Přenést část logiky do databáze (tedy blíže datům) je možné v Oraclu, PostgreSQL, DB/2 … a dokonce i v té MySQL.

Článku by prospělo méně PR a (pseudo)argumentů pro „jedinou správnou platformu“ a více praktických tipů, jak se s touhle exotickou platformou má člověk vyrovnat, když už ji musí používat.
(Ano, exotickou, protože pokud se bavíme o PHP webech, jsou Windows skutečně exotem).

P.S. Vím sice, že polemika s autorem nikam nepovede, ale stejně mi to nedalo :-)

lépe řečeno: LIMIT m OFFSET n

+1
ps. Netuším, proč má tvůj komentář negativní hodnocení. Asi zapracovali trollové z Hulan-blogu… :-)

No to je snad na obou platformách otázka systémových práv…

…aneb povinny restart kazdy den ve 3 rano.
http://social.msdn.microsoft.com/…3c708118383c

Ten memory leak problém existoval v SQLSRV driveru 1.0, v 1.1 je vyřešen.