Microsoft FastCGI - maar werkte zou u bij moeten bevorderen?
Wij eerder behandeld de definitieve versie van de module IIS FastCGI, die gezamenlijk tussen Microsoft en Zend wordt ontwikkeld… Maar enkel deze week, Microsoft (MSFT: $33.76 -0.50%) aangekondigd de beschikbaarheid van RTM van de module IIS FastCGI.
Zo wat gebeurt? Wij hebben de huidige versie gedownload (die, door de manier, is niet het compatibele systeem met oude, u moet dan desinstalleren installeert de nieuwe versie) en gecontroleerd het versieaantal op \ Vensters \ System32 \ inetsrv \ fcgiext.dll - het kwam uit 6.1.36.1 te zijn.
Door contrast, de versie die wij en een maand hebben gedownload geleden (die de Go Live versie) schijnt gesynchroniseerd te zijn werden gecontroleerd en werden gevonden om 7.0.6001.16606 te zijn geïnstalleerd.
Duidelijk gebruikte de Go Live versie de nummering van de versies van de Server 2008 van het Microsoft Windows, maar het heeft verward ons.
U kunt vinden een chronologie van de ontwikkeling en de mijlpaalcyclus Mike Volodarsky (de ontwikkelaar van Microsoft IIS)' s van de module FastCGI blog - maar het maakt geen vermelding van de versie van Oktober van om het even welke aard 10de 2007.
Wat het meest verward heeft is niet het gebrek aan een volledig versieprogramma noch de tegenstrijdige versieaantallen - die zijn gemakkelijk. Zoals met de meeste andere toepassingen, is het recentst grootst - eind van verhaal. Voor ons, het probleem is dat de module RTM FastCGI dan de Go Live versie van vorige maand minder stabiel is. Dit is echte slechte nieuw, omdat de module FastCGI ontzagwekkend en onschatbaarste hulpmiddel is geweest wanneer het over het opstellen van bepaalde open-bronmodules met fouten op Vensters komt.
Onze ervaring met de module RTM is FastCGI niet al slecht geweest - de prestaties zijn lichtjes geweest (zoals binnen < 1 req/seq) beter. Maar de bevordering is een PITA en de module RTM zou door het configuratiedossier niet de eerste keer verblijven wij het installeerden - zodanig dat het onze PHP dossiers als duidelijk-tekst diende, een REUSACHTIGE veiligheid geen-nr. Maar schrapten wij toen het configuratiedossier en begonnen van kras en alles was O.K.…
Maar toen begonnen de processen FastCGI te verhinderen en op te houden met, waren de verzoeken timing uit te snel (ondanks het gebruiken van de zelfde richtlijnen van het configuratiedossier), en snel-ontbreken bescherming te vaak werden in dienst genomen veel.
Het schijnt dat de onderbrekingssyntaxis aan de originele semantiek van de vroegere versies voorafgaand aan de Voorproeven van Technologie is teruggekeerd, waar ActivityTimeout in zal schoppen is zelfs RequestTimeout nog niet bereikt…. Maar wij zijn niet zekere.
Op het ogenblik schijnen onze problemen ontward te zijn (door alle grenzen in ons configuratiedossier door a op te heffen partij ) maar natuurlijk, heeft alles zijn prijs. We’re hoping that raising the timeouts won’t induce and instability or end up with FastCGI module unable to detect a hanged process - but only time will tell.
In the meantime, if you’re running the October 2007 release (which, by the way, we cannot seem to locate any more) you should probably hold off upgrading for a week or two until things get sorted out.
Written by Computer Guru. Read more great feeds at is source WEBSITE
no comments.
Read more articles on FastCGI and IIS and Microsoft and Reviews and Windows and software.
- [+] Digg: Feature this article
- [+] Del.icio.us: Bookmark this article
- [+] Furl: Bookmark this article
