FastCGI kiterjesztés IIS-hez a Microsoft-tól

PHP

2006 elejétől a Microsoft és a Zend a PHP közösséggel együttműködve azon dolgozott, hogy jelentősen növelje a PHP megbízhatóságát és teljesítményét Microsoft Windows 2003 és 2008 szervereken. Ennek az együttműködésnek részeként az Internet Information Services (IIS) csoport egy új IIS6 és IIS7 komponensen dolgozik, amelynek a neve "FastCGI Extension". A kiterjesztés a PHP alkalmazások sokkal hatékonyabb hostolását teszi lehetővé IIS környezetben. A Microsoft nemrég bejelentette a Microsoft FastCGI Extension for IIS 5.1/6.0 (FastCGI Extension) szabad letölthetőségét. Bővebben itt.

Szerintem Bástya arra célzott, hogy sok lúzer developzor fejleszt a gennyes windózán, mer' nem lát túl rajta, vagy egyéb indokok késztetik ilyen mazoizmussal felérő tettekre.
De egy nagy cégnek meg a win 2k3 server nem tétel.

De nézd meg pontosan mi is ez: w2k3 meg w2k8 szerver miatt csinálják ezt.

Ott ahol ez a szerver már adott eléri evvel az ms, hogy ne apache-ot, tegyenek az ő szerverük mellé, vagy az iis helyett, vagy még egy un*x szervert, hanem a saját ügyfélkörét köti evvel jobban magához. És el kell ismerni, az ő üzleti szemponjukból ez egy kurva jó húzás volt!

szal mitnemérc'?

Szerintem Bástya arra célzott, hogy sok lúzer developzor fejleszt a gennyes windózán, mer' nem lát túl rajta, vagy egyéb indokok késztetik ilyen mazoizmussal felérő tettekre.

Nem. :-)
Egyébként az is benne van, hogy ugye a FAstCGI-nek van egy olyan baromi jó tulajdonsága, hogy az interpreter, ami a webszerverrel kommunikál, futhat külön gépen (bár AFAIK ezt valahogy az ISAPI is tudja a megosztott COM+ objektumok révén, csak akkor a másik gépnek is Winnek illik lenni. :-P)
A FastCGI nagyon népszerű pl. RoR-körökben (tehát nem csak PHP-t lehet alá developzorkodni, csak éppen a Zend-del fejlesztette a Microsoft, ez ilyen koincidencia, tehát megy a félrevezetés rendesen).
Egyébként meg olyan nincs, hogy "fastCGI meg IIS alá fejleszteni", mert a jó PHP-script elvileg szerverfüggetlen.
It doesn't matter if you like my song as long as you can hear me sing

Amikor legutoljára használtam PHP-t Windowson, valami alap függvénnyel (nem emlékszem már, hogy melyik volt az) kifagyasztotta az IIS-t. Szóval ennél az apacs csak jobb lehet :) Bár tény, hogy Windowson az apacs lassú.

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

( trey | 2007. 10. 10., sze – 22:45 )

Gondolom ezzel a "spagetti PHP" majd enterprise megoldássá válik azon nyomban ;)

--
trey @ gépház

Azért PHP-ben is lehet komoly dolgokat csinálni. Nem a nyelv a lényeg, hanem a tervezés és az algoritmusok... Nyelvet meg sok szempont alapján választ az ember, és a PHP szinte verhetetlen néhány dologban:
- dokumentáltság
- beépített függvények sokasága, és ezek közt rengeteg nagyon hasznos függvény van
- jó OOP (Java/C++ szintet nem ér el, de pl a python-nál sokkal többet tud)
- az OOP-hez képest annyira nem lassú
- mivel scriptnyelv, ezért élvezi minden előnyét, főleg rugalmasság terén (egyszerű bővíthetőség)

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

Olvasgatom, milyen szépeket, és jókat írogat itt a kolléga, mikor megakad a szemem ezen:

"jó OOP (Java/C++ szintet nem ér el, de pl a python-nál sokkal többet tud)"

Kérdem én:
Mit nem tud a python, amit a php igen? Mi a baj a python OOP részével?

------------------------------------------------------
Aki utoljára nevet, annak van 56k-s modeme.

destruktor, private/protected változók, eljárások... ennek az apróságnak a megtalálását napokig gugliztam. Ha van ilyen, akkor megosztanád velem (nem fikázok, komolyan kíváncsi vagyok)?

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

pl.: nincsen destruktor (ez java-nál is zavar), nincs rendes private tag benne:
"it still is possible for a determined soul to access or modify a variable that is considered private" (forrás: http://docs.python.org/tut/node11.html). Nincsen protected tag sem benne.
Összesen ennyi. Amúgy nem fikázni akarom a python-t, nagyon szeretem, jó kis nyelv.

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

Pedig marha hasznos tud lenni a destruktor. Pl van egy objektum, ami adatbázist kezel, ekkor a konstruktor kapcsolatot nyit, a destruktor pedig automatikusan az objektum megsemmisülésekor zárja azt.

Elhiszem, hogy tervezéskor döntöttek így, de nekem ez marhára nem szimpatikus.

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

A destructorra nem tudok mit mondani, a többiek már elmondták.
Private van az 5-ös pythontól kezdve, ha két aláhúzással kezdel egy adattagot/metódust, az private lesz.
pl: __adattag, __metodus()

------------------------------------------------------
Aki utoljára nevet, annak van 56k-s modeme.

Igazából szerintem ez a finalize metódus még akkor került bele, amikor nem volt teljesen kiforrott a GC koncepció. Manapság már teljesen felesleges és ellenjavalt a használata, nem is értem, hogy milyen szerepe lehet még. Valaki tud esetleg olyan esetet, amikor érdemes/kell használni?

( jzola v | 2007. 10. 11., cs – 00:18 )

azért valahol ms is tudja hogy komoly php siteot senki nem fog ezután se iis en futtatni.(aki meg igen az hülye, ha persze nem valami extra windowsos cucc kell sitehoz)

vagy kitudja owa, sharepoint php alapu lesz :D

Nekem nincs tapasztalatom a PHP-vel, de akikkel beszeltem erveket is mondtak, es hitelesnek tuntek, szoval elhittem nekik. Pl. ilyesmi, hogy az objektumorientalt modell allandoan valtozik verzionkent, a tipusrendszer nem biztonsagos, gyengen tipusos nyelv, tobbparadigmas nyelv. A modulrendszer nem tul kiforrott, es sok a hibas implementacio a meglevo modulokban. Tesztelni nehezkes.

Nyugodtan javitsatok ki, ha rosszul mondok valamit.

- oo modell: változik, mert bővül; visszafelé kompatibilis a legtöbb esetben (bár nekem még egy sort nem kellett átírnom PHP verzió változás miatt; ugyanúgy futnak a PHP4 kódjaim is, mint a PHP52-esek)
- típusrendszer: ebben van valami, de ez a scriptnyelv mivoltából ered, így nem kell folyton konvertálgatni; de tény, hogy néha zavaró tud lenni (de erre van pl a settype()/gettype() fgv)
- a modulrendszerre nem tudok pro/kontra mondani sokat, mert nem sokat használok (postgres, gd2, mysql meg egy pár még), de azokra panasz nincsen eddig; vannak viszont kísérleti modulok (pl winapi bindingek), azzal lehetnek gondok
- ami rossz, pl következetlen elnevezések: hol egybe vannak írva a szavak, hol _-sal vannak elválasztva

Ahogy kezdek belemerülni a webprogramozásba vállalati szinten (a nem programozó kollégák mesélnek), kezdek rájönni, hogy miért fikázzák annyira a PHP-t: mert sokan nem tudnak programozni, csak kódolni (különbség: kódolás: forráskód gépelés; programozás: algoritmus megtervezése, részproblémákra bontása, azok megvalósításának megtervezése, aztán kódolás). Csak PHP-hez értenek (Javahoz pl abszolút nem), és nekikezdenek egy weblap megírásához. Mivel nem tervezik meg, ezért ismeretlen számukra az olyan fogalom, hogy sablon, így ömlesztik a PHP és a HTML kódot. Nem tartanak be semmilyen rendszerezési szabályt (pl illik minden class-t külön fájlba rakni, meg úgy egyáltalán valami rendszert tervezni az egésznek; pl nem írunk két html kód közé egy sql lekérést). Így működik a lap, de ha bővíteni/átalakítani, vagy javítani kell a kódot, akkor már karbantarthatatlan. Írnak 20 ilyen lapot, és kész a káosz. Emiatt persze a PHP a szar, nem a kóder, aki köszönő viszonyban sincs a tényleges programozással.
Alapos tervezéssel viszont lehet PHP-ben elég komoly rendszereket összerakni, amik valóban vállalati szintűek, csak ehhez vállalati szintű programozó kell.

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

"Alapos tervezéssel viszont lehet PHP-ben elég komoly rendszereket összerakni, amik valóban vállalati szintűek"

Egyetertek nagyjabol, de spec ez a mondat igaz akar az assemblyre is. En ezzel szemben azt gondolom, hogy egy modern nyelvnek, de legalabb a fejleszto kornyezetnek tamogatnia kell a rossz programozasi szokasokat, csapdakat elkerulo modszereket. Tehat ha PHP-ben lehetoseg van az altalad irt szerencsetlen mixelesre, akkor azt en a PHP (vagy a hozzatartozo feljeszto kornyezet) hibajakent rohatom fel (egy idealis vilagbol kitekintve, hiszen valojaban tudjuk, hogy a valosagban ez csak egy problema a vegtelen kozul).

Ezt az osszekeveredesi problemat en eleg sulyosnak latom ahoz, hogy ne szulessen ra valami tamogatott megoldas, hogy ne essen bele mindenki. (Szvsz eleteben parszor mindenki beleesik ilyen jellegu csapdakba.) De ez mar csak fantazialas.

Ezt a szerencsétlen mixelést kb minden nyelven el lehet követni (java-t nem tudom, hogy hogyan viszonyul az outputhoz; de cgi-bin esetén is simán (perl, c, c++, asm akár), vagy bármilyen más scriptnyelv (python pl) is képes erre).

Van rá megoldás, pl.: MVC modell (teljesen el kell szeparálni a részeket az alkalmazásban; külön az egész adatbáziskezelés, külön a megjelenés, külön a "business logic"), különböző sablon rendszerek. Csak nem használják, mert a turbo pascal-ban sincs ilyesmi (aki ilyeneket követ el, az pedig gyakran azon "nevelkedett"). De egy tervezési hibát akkor sem a nyelv feladata kikerülni.

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

"Ezt a szerencsétlen mixelést kb minden nyelven el lehet követni "

Minden altalanos celu nyelvben valoban, de szvsz a PHP domain specifikus nyelv, igy szvsz az, hogy a sajat problema domainjara jobban fokuszaljon, elvarhato. Mindegy, reszletkerdes.

Viszont van egy szemlelet, amit fontosank tartanek, es nyomtanam az open source vilagban, hiszen itt sokan fogekonyak az innovaciora. Ez a szemlelet pedig az, hogy ne gondoljuk a rendszer megvaltoztathatatlan tulajdonsaganak peldaul az altalad emlitett "MVC modellnek" azon jelleget, hogy nem fejezheto ki (altalanos celu) nyelvi elemekkel, azaz az illeto fejleszto/designer felelosege, hogy betartsa/betartassa (pl) a koncepciok szeparalasat. Ezek sajnos csak okolszabalyok, opcionalisak, nincsen eszkoz a kotelezo betarthatosagara. Nagyon hasznosak talalnam, ha peldaul letrejonnenek uj domain specifikus nyelvek es a jelenleg aktualis problemakat celoznak, levennek a hatamrol azt a terhet, hogy ezzel is nekem kelljen foglalkoznom. Ehez hasonlo jelenseg "kicsiben" mar lejatszodott (parszor), (pl) akkor amikor letrejott az OO programozas, a tipus kenyszerites, azaz amikor olyan eszkozkeszletet kaptunk, ami relativ szuk keretek koze szoritja a fejlesztot a szigoru tipusvizsgalatok ellenrozesevel. Ezt lehetne csinalni domain specifikusan is, be lehetne vinni a webfejleszto kornyezetekbe azt a tudast, hogy hasznos szeparalni a tartalmat a logikat es a kinezetet egymastol.

( Aikon | 2007. 10. 11., cs – 07:17 )

lol :). WIMP = Windows + IIS + MSSQL + PHP

windows, icons, mice and pointers
Why Isn't Mary Programming
Women-Influenced Male Person
Woman In Men's Pants
Weakly interacting massive particle
vagy
WAMP A Microsoft Windows-based variant of a LAMP (software bundle).
whip - http://en.wikipedia.org/wiki/Whip
wasp - White Anglo-Saxon Protestant

Ruhellem az amerikai beszedben, lepten nyomon elofordulo acronymakat. Foleg amikor katonak beszelgetnek.

( york | 2007. 10. 11., cs – 11:39 )

Elterve az IIS-tol, apache-ban miert jobb a FastCGI mint a mod_php?

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Biztonságosabb, több interpretert futtathatsz, akár teljesen külön beállításokkal, külön verziókkal (pl. egyik vhosthoz 4.x, mert nem lehet updatelni, másikhoz 5.2, mert az az aktuális, egy másikhoz egy továbbit egy külön gépen, hogy legyen elég CPU idő az alapgépen, meg felraksz még egy 6.x-dev-t is, mert valakinek tesztelhetnéke van).

FastCGI tesztek alapján valamivel lassabb, mint a mod_php, viszont valami alternatív webszerverrel (lighttpd-vel megy nálunk, pl.) lényegesen gyorsabb is tud lenni.