Toon posts:

IIS 6 + PHP traag (zelfs op LAN)

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hallo,

Ik heb een vraagje. Ik had van origine apache draaien (Xampp) als webserver. Dat liep allemaal prima. Tot ik e-mail (Exchange) op mijn mobiel wilde. Ik moest hierdoor IIS als webserver gebruiken. Daar heb ik PHP op geinstalleerd en de websites welke onder Apache draaiden werkend gekregen op IIS. Echter leek dit enorm veel trager (zeker factor 10). Ik ben eens gaan tweaken met extra processen in IIS en geheugengebruik en dat leek het iets te verbeteren.

Echter lijkt het nog steeds traag. Ik heb in mijn script via php mijn page load time gezet en die is steeds maximaal 0.08 seconden. Dat is dus lekker snel. Echter duurt het tot wel 6 seconden (makkelijk) voor de browser (zowel FireFox 3, FireFox 3.5 als IE 8) voordat deze stopt met laden (vaak is wel de pagina na 3 seconden volledig zichtbaar). Dit is vanaf extern ip (heb glasvezel thuis, 50 Mbit up), intern ip (100 Mbit) als Lokaal. Dit lijkt mij erg vreemd. Ik heb de grootte van de afbeeldingen bekeken, misschien zou het daaraan kunnen liggen, maar dat blijkt het ook niet te zijn. De totale grootte aan afbeeldingen is misschien maximaal 200kb, dus dat is ook niet noemenswaardig (zeker lokaal en via lan).

Heeft iemand enig idee wat ik zou kunnen proberen of hoe ik erachter kan komen waardoor het zo traag is. Ik vind 6 seconden wachten toch enorm veel voor een website. Zeker als dezelfde website geserveerd via Apache wel gewoon snel klaar is.

Zou het kunnen komen door mijn CSS omdat ik vrij veel DIV's gebruik voor de opmaak?

Enig idee wat de browser aan het doen zou kunnen zijn als de website volledig weergegeven wordt, maar de laadt balk nog wel enige tijd op zich laat wachten? Ik heb al vanalles gezocht, maar nergens een goed antwoord kunnen vinden. Alvast bedankt.

  • DigiK-oz
  • Registratie: December 2001
  • Laatst online: 13:07
Installeer in Firefox de plugin Firebug (als je die al niet hebt), daarmee kan je exact zien wat er lang duurt om binnen te halen.

Wat betreft je probleem, misschien refereer je in PHP naar iets (extern?) dat om wat voor reden dan ook door IIS niet te vinden is en/of een timeout oplevert? Misschien sluit je de page niet netjes af en gaat apache daar anders mee om dan IIS?

Whatever


  • alt-92
  • Registratie: Maart 2000
  • Niet online

alt-92

ye olde farte

Verwijderd schreef op donderdag 16 juli 2009 @ 00:47:
Hallo,

Ik heb een vraagje. Ik had van origine apache draaien (Xampp) als webserver. Dat liep allemaal prima. Tot ik e-mail (Exchange) op mijn mobiel wilde. Ik moest hierdoor IIS als webserver gebruiken. Daar heb ik PHP op geinstalleerd en de websites welke onder Apache draaiden werkend gekregen op IIS. Echter leek dit enorm veel trager (zeker factor 10). Ik ben eens gaan tweaken met extra processen in IIS en geheugengebruik en dat leek het iets te verbeteren.

Echter lijkt het nog steeds traag.
Hoe heb je PHP met IIS draaien? de ISAPI module is niet supersnel namelijk, maar als je FastCGI gaat gebruiken scheelt het echt behoorlijk wat in snelheid.
http://learn.iis.net/page...p-applications-on-iis-60/
http://www.iis.net/downlo....aspx?tabid=34&i=1521&g=6

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device


Verwijderd

Topicstarter
Oh My God. Ik gebruik de firebug plugin al, maar dat ik er niet eens zelf ben opgekomen om daarnaar te kijken. Dat kan ik natuurlijk wel even doen. Bedankt voor die tip. Mijn php script refereert iig niet naar iets externs. Hoe kan ik controleren of de page netjes afgesloten wordt? Ik gebruik gewoon de buffer met een flush netjes aan het einde (via header en footer file).

De installatie van php is alweer een tijd geleden en ik weet dat dat veel problemen heeft opgeleverd. Ik durf niet met zekerheid te zeggen welke van de 2 het is. Ik zie bij Web Service Extensions dat ik verwijs naar de php-cgi.exe uit de php map. Is het dan de fastcgi versie? Ik heb destijds gewoon een tutorial gebruikt welke ik op internet heb gevonden. Dat werkte dus verder niet naar gekeken.

  • alt-92
  • Registratie: Maart 2000
  • Niet online

alt-92

ye olde farte

Als je geen FastCGI hebt geinstalleerd (en jij verwijst rechtstreeks naar de php cgi module en da's nog trager dan de ISAPI) dan gebruik je die niet.

Ik kan het je wel aanraden om echt even opnieuw te beginnen en alle references naar php uit zowel de sites als de server zelf te halen en goed op de versies te letten.
PHP 5.2.10 werkt voor mij perfect met fastCGI.

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device


Verwijderd

Topicstarter
Hallo,

Ik heb de log van firebug bijgevoegd en zoals ik al vermoedde gebeurd er gewoon 5 seconden helemaal niks. Echt geen enkele aanwijsbare reden waarom. Of zou de browser zo lang doen over het parsen van de css (alhoewel die maar 11 kb is). Zou fastcgi dit probleem echt oplossen?

[ Voor 10% gewijzigd door Verwijderd op 29-07-2009 16:22 . Reden: afbeelding weggehaald ]


  • Fonta
  • Registratie: Juli 2007
  • Laatst online: 19-01 10:18
Verwijderd schreef op donderdag 16 juli 2009 @ 18:06:
Hallo,

Ik heb de log van firebug bijgevoegd en zoals ik al vermoedde gebeurd er gewoon 5 seconden helemaal niks. Echt geen enkele aanwijsbare reden waarom. Of zou de browser zo lang doen over het parsen van de css (alhoewel die maar 11 kb is). Zou fastcgi dit probleem echt oplossen?

[afbeelding]
Ik zou zeggen, probeer het eens. Dan weet je het snel genoeg.

  • alt-92
  • Registratie: Maart 2000
  • Niet online

alt-92

ye olde farte

Verwijderd schreef op donderdag 16 juli 2009 @ 18:06:
Hallo,

Ik heb de log van firebug bijgevoegd en zoals ik al vermoedde gebeurd er gewoon 5 seconden helemaal niks. Echt geen enkele aanwijsbare reden waarom.
tot zover de client, dan ga je toch je pijlen richten op je server?

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device


  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 16:25
Fastcgi maakt idd een groot verschil. Zonder fastcgi moet IIS elke keer een php-cgi.exe proces opstarten bij het aanvragen van een pagina. Dit vreet tijd, alhoewel de tijd die jij meet wel ontzettend lang is. Heb je er verder nog dingen als on-access virusscanners op draaien ofzo?
Bij Fastcgi wordt 1x PHP opgestart, en blijft draaien net zolang tot een aantal scripts zijn uitgevoerd, php crasht of IIS opnieuw gestart wordt. Ik gebruik vanwege veiligheidsredenen deze methode op linux ipv de geintegreerde module, en uitgezonderd de eerste request na het starten van apache, is het gewoon net zo snel als de ingebouwde apche module.

  • Exception
  • Registratie: Augustus 2006
  • Laatst online: 16:04
Wat gebeurd er als je je website d.m.v.http://127.0.01/ aanroept in plaats van http://localhost/ ? Bij mij zit hier merkbaar verschil tussen.

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Simpele vraag, wat laat je allemaal via php opbouwen? Want als ik het plaatje zo zie dan is je php na 178 ms weer weg en is het enkel een extreem bokkende IIS die geen 304 headers meer kan serveren...

Of je laat je plaatjes / css via een php script lopen of php heeft er imho niets mee te maken...

Statische data kan IIS makkelijk serveren, alleen lijkt het wel alsof er iets speciaals gebeurt met jpg's op die server ( anti-virus misschien )

Fastcgi/isapi is volgens mij geen oplossing ( alhoewel uiteindelijk wel een totale verbetering ) voor dit probleem, je php is gewoon in 178ms klaar...
Exception schreef op donderdag 16 juli 2009 @ 20:01:
Wat gebeurd er als je je website d.m.v.http://127.0.01/ aanroept in plaats van http://localhost/ ? Bij mij zit hier merkbaar verschil tussen.
Als hier merkbaar verschil tussen zit zou ik maar eens je dns-instellingen gaan controleren. Ergens zit iets iets van een verkeerde dns-server af te halen...

[ Voor 25% gewijzigd door Gomez12 op 16-07-2009 20:22 ]


Verwijderd

Topicstarter
Bedankt voor de reacties zover.

Ik was mijn pijlen al op de server aan het richten, maar dat is een 2003 Enterprise met Exchange Enterprise (lang leve studentlicenties :D) op een Pentium 3.0 Hyper Threading met 1,5 GB. Ik dacht eerst dat het een capaciteits probleem was.

Er draaide een antivirus programma op (McAfee, maar ben ik niet zo tevreden over dus heb ik eraf gehaald). Had ook Adaware draaien, maar heb ik er ook maar afgegooid. Ben verder nog even wat andere applicaties aan het verwijderen. Het lijkt er echter niet op dat dit helpt. DNS is het ook niet. Ik heb namelijk mijn DNS instellingen in de hosts file gezet (dit omdat het lokaal draait en anders de dns instellingen extern opgevraagd gaan worden en ik een systeem gebruik buiten de Active Directory om).

Ik vind het ook zo vreemd dat het gewoon zolang duurt voordat hij de afbeeldingen gaat serveren.

Hoe bedoel je de vraag: Wat laat je allemaal via php opbouwen? Ik gebruik php enkel om wat data uit de database te halen. Maar dat zijn simpele queries en als ik de php timer functie gebruik om te kijken hoe lang de pagina duurt scheelt dat dus ook weer net die 5 seconden. Dit komt namelijk onderaan mijn pagina:
<!-- Pagina geladen in 0.81169 seconds. -->

Ik ga wel eens even kijken naar fastcgi, alhoewel ik niet het idee heb dat het daaraan zal liggen (iig niet ruim 5 seconden wachttijd). In de eventlogs staat ook niks aanwijsbaars.

[ Voor 0% gewijzigd door Verwijderd op 16-07-2009 20:59 . Reden: typo ]


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Verwijderd schreef op donderdag 16 juli 2009 @ 20:57:
Hoe bedoel je de vraag: Wat laat je allemaal via php opbouwen? Ik gebruik php enkel om wat data uit de database te halen. Maar dat zijn simpele queries en als ik de php timer functie gebruik om te kijken hoe lang de pagina duurt scheelt dat dus ook weer net die 5 seconden. Dit komt namelijk onderaan mijn pagina:
<!-- Pagina geladen in 0.81169 seconds. -->
Laat maar zitten dan, ik dacht dat je misschien je plaatjes door php liet serveren ( bijv via gd om automatisch te resizen / gd generated plaatjes oid )
Maar als je php enkel gebruikt om die .php te serveren dan zou je als test eens kunnen kijken of je die gegenereerde html-brondcode niet gewoon als index.html kan opslaan en dan kijken of het probleem daarmee nog steeds is.

Zoja, dan gaat je server gewoon zwaar door de bocht, zonee dan sluit php niet lekker af ofzo ( wat mogelijk op te lossen is door fastcgi maar ik betwijfel het )

Verwijderd

Topicstarter
Daar heb je een goed idee gegeven. Pagina geladen, opgeslagen als .htm. Naar server gekopieerd, daarna die pagina geopend. Hij is nu gewoon zoals het zou moeten, 513ms nog maar volgens firebug. Geen irritante laad opties meer, gewoon zoals verwacht en zoals hoe het via apache initieel ook ging.
Ben al tutorials over fastcgi aan het zoeken, hoe ik die geïnstalleerd krijg.

Heb hier een mooie te pakken denk ik: http://learn.iis.net/page...cgi-extension-for-iis-60/
Die maar eens proberen.

  • gertvdijk
  • Registratie: November 2003
  • Laatst online: 16:05
Of je gebruikt gewoon weer Apache, zoals het altijd werkte en je proxiet door naar IIS voor de Exchange functionaliteit...

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog


  • hostname
  • Registratie: April 2009
  • Laatst online: 02-02 19:46
PHP heeft vanaf 5.3 wel een (enorme) update gegeven aan alle Windows builds, misschien dat is proberen? Sowieso mis ik je PHP versie.

Verwijderd

Topicstarter
Nice! Fastcgi geïnstalleerd en het loopt als een trein! Moet alleen weer even mijn exchange omgeving aan de praat krijgen, maar daarvan afgezien lijkt het allemaal prima! Bedankt allen die hebben gereageerd en meegeholpen met het zoeken naar en oplossen van het probleem!

ps: Ik gebruik liever niet meerdere webservers en nu lijkt het wel gewoon goed te draaien.
ps2: Ik gebruik nu PHP Version 5.2.9-1, maar misschien dat ik hem maar eens moet updaten dan, kan sowieso geen kwaad denk ik
Pagina: 1