Onderwerp: IIS 6, PHP 5 en FastCGI

Ik heb even getwijfeld tussen dit forum en Scripting, Techniek & Beveiliging, maar misschien dat iemand van Microsoft hier ook wat over kan zeggen...
Graag zou ik eens van conculega's horen hoe zij PHP (5.2.5) in FastCGI op IIS 6 geïmplementeerd hebben. Denk dan aan bijvoorbeeld:
- applicatiepools, de aantallen hiervan en de user instances waaronder zij draaien
- performance server (geheugen en CPU gebruik)
- ...
- ...

Wij zijn hier een beetje mee aan het vogelen en het wil nog niet echt zoals wij het hebben willen... Mocht iemand Perl als FastCGI voor elkaar hebben gekregen, dan hoor ik dat ook graag.

Na een hoop klachten van klanten dat sommige extenties van OS-applicaties als Word-press en Joomla/Mambo niet werkten in de ISAPI module (tread-safety), heb ik fCGI geinstalleerd zoals op de site van IIS.NET vermeld staat:
http://learn.iis.net/page.aspx/247/u...ons-on-iis-60/

Ik gebruik HELM als control-panel. De app-pools draaien onder de web-users van de websites (standaard in HELM), vaak als domein.ext_web. Ik gebruik volledige application-pool isolation, vooral omdat voorheen met de ISAPI module deze app-pools af en toe automatisch werden uitgeschakeld door IIS door de vele fouten. Ik heb eigenlijk niet bekeken wat het effect is op het geheugengebruik tussen ISAPI en fCGI, beide met app-pool isolation.

Thanks!

Oorspronkelijk geplaatst door EWMS

De app-pools draaien onder de web-users van de websites (standaard in HELM), vaak als domein.ext_web. Ik gebruik volledige application-pool isolation [...]

Hoe veel afzonderlijke AppPools draai je (ongeveer) en heb je in het registry nog wat gedaan betreft de UseSharedWPDesktop key?

Ongeveer 40. Daarom gebruik ik ook (nog) geen shared desktop. Het is niet altijd even duidelijk wat de concequentie is van het delen van die desktop. Op http://blogs.msdn.com/david.wang/arc...p_on_IIS6.aspx wordt geschreven:

"Obviously, the security considerations are for you to consider... that is why there is a choice. :-) IIS itself has no sensitive data to share in the desktop, but security-paranoid administrators tend to not want processes of different application pool to share anything to prevent the potential of having desktop shatter attacks and the like."

Misschien dat andere dit kunnen toelichten of kunnen aangeven wat ze waarom hebben gekozen. Ik loop binnenkort ook tegen deze 'limiet' aan...

Inderdaad. Ik voel er op dit moment weinig voor om een aantal honderd AppPools met eigen user instances aan te maken, daar ik geen idee heb wat dit doet qua performance.
Het is te testen, maar in een test omgeving kom je nooit in de buurt van de werkelijkheid (maak een honderdtal AppPools en websites aan, plaats er applicaties en roep deze aan via bijvoorbeeld WCAT of eenvoudigweg met cURL).

Oorspronkelijk geplaatst door Digiover

Inderdaad. Ik voel er op dit moment weinig voor om een aantal honderd AppPools met eigen user instances aan te maken, daar ik geen idee heb wat dit doet qua performance.
Het is te testen, maar in een test omgeving kom je nooit in de buurt van de werkelijkheid (maak een honderdtal AppPools en websites aan, plaats er applicaties en roep deze aan via bijvoorbeeld WCAT of eenvoudigweg met cURL).

// Edit: Zonder de UseSharedWPDesktop registry entry kom ik tot 74 draaiende AppPools. Met de entry tot in ieder geval 75 (nog niet verder getest).