PHP of Apache echo() erg traag

Topicstarter

Ik weet niet of het aan PHP of aan Apache ligt, maar wel dat het een vreemd probleem is. Wat er aan de hand is is het volgende (om het probleem te verduidelijken heb ik het PHP-script sterk vereenvoudigd):

Er is een PHP-script dat niets anders doet dan een tekst van ongeveer 44 kB weergeven en meten hoe lang dat duurt. Op mijn eigen computer, Athlon 600 met Apache, PHP en Windows 2000, en een Linux-testserver, Apache, PHP en een 486 processor, duurt dit slechts een fractie van een seconde.

Het zelfde script uitgevoerd op een 1000MHz server met Apache/1.3.20 (Unix) (Red-Hat/Linux) PHP/4.0.6 duurt maar liefst 2 seconden. Dat lijkt mij erg lang.

Heeft iemand enig idee waar dit aan kan liggen?

zondag 10 februari 2002 13:30

Acties:

zondag 10 februari 2002 13:33

Software Architect

Werkt hier

Waar staat die 1Ghz server?

En hoe druk heeft die het?

Acties:

Topicstarter

Die staat op school achter de Kennisnet-reverse-proxy. Hij heeft zo goed als niets te doen. Er staat geloof ik wel iets als dnetc op, maar dat hoeft volgens mij niet zo heel veel uit te maken.

zondag 10 februari 2002 13:39

Acties:

D2k

vraag de load eens op??

Doet iets met Cloud (MS/IBM)

zondag 10 februari 2002 13:39

Acties:

Config

gewoon ff kijken met top?

zondag 10 februari 2002 13:40

Acties:

D2k

Op zondag 10 februari 2002 13:39 schreef Config het volgende:
gewoon ff kijken met top?

PHP:

1
2
3

<?
 $uptime = (exec("uptime")); echo "$uptime";
?>

Doet iets met Cloud (MS/IBM)

zondag 10 februari 2002 13:41

Acties:

Topicstarter

Of met phpSysInfo, ook leuk.

Hier komt ie dan: 1.04 1.05 1.23

zondag 10 februari 2002 14:34

Acties:

Verwijderd

DNETC.... daar heb je al een probleem.
Die clients pikken nogal veel tijd in.
Welliswaar wordt er altijd terug geschakeld om processor tijd vrij te krijgen, maar hier zit altijd een respons tijd aan vast. (In mijn ervaring) waardoor het geheel langzamer gaat draaien.

Verder kan het ook zijn dat de Reverse DNS niet werkt,
waardoor de APACHE blijft wachten op IP -> Name conversion (dit duurt echter meestal langer als 'slechts' 2 seconde)

zondag 10 februari 2002 14:38

Acties:

Kettrick

Rantmeister!

Op zondag 10 februari 2002 14:34 schreef underdog78 het volgende:
Verder kan het ook zijn dat de Reverse DNS niet werkt,
waardoor de APACHE blijft wachten op IP -> Name conversion (dit duurt echter meestal langer als 'slechts' 2 seconde)

PHP wordt pas geparsed als de webserver de remote host gevonden heeft.

Even voor de duidelijkheid, duurt het 2 seconden voordat de pagina er staat, of duurt het parsen van php 2 seconde ?

zondag 10 februari 2002 14:41

Acties:

zondag 10 februari 2002 17:52

Software Architect

Werkt hier

Op zondag 10 februari 2002 14:34 schreef underdog78 het volgende:
DNETC.... daar heb je al een probleem.
Die clients pikken nogal veel tijd in.
Welliswaar wordt er altijd terug geschakeld om processor tijd vrij te krijgen, maar hier zit altijd een respons tijd aan vast.

Daar merk je dus helemaal niks van he?

Zeker geen 2 seconden.
Waarschijnlijk zit het probleem hem in het volgende:
Server bakt htmlpage (kost tijd, niet al te veel), proxy pakt page aan en cached die (moest hem dus eerst van de server downloaden, kost wederom tijd ook weer niet echt veel) en vervolgens moet de page geupload worden naar jou.

Dat opgeteld kan genoeg tijd kosten, daarnaast moet de tekst ook nog eens door jou gedownload worden.

Wat je eens kan testen is het volgende:
Genereer een pagina met behulp van de ob_* functies. Dan wordt er nog niets opgestuurd, kijk hoe lang het duurde tot dat je ob_endflush (oid) roept en kijk dan nog even hoe lang het duurde om die endflush uit te voeren.

Acties:

Topicstarter

Nee, het is niet de tijd tussen het opvragen en het op het scherm verschijnen, het is alleen de tijd die PHP nodig heeft om de tekst naar de server te sturen.

Het volgende script:

code:

<?php
    function jointime($mtime) {
      // split up the output string from microtime() that has been passed
      // to the function
      $timeparts = explode(" ",$mtime);
      // concatenate the two bits together, dropping the leading 0 from the
      // fractional part
      $finaltime = $timeparts[1].substr($timeparts[0],1);
      // return the concatenated string
      return $finaltime;
    }
    
$begintijd = jointime(microtime());

ob_start();

?><!--
hier de lange tekst
 -->
<?php

echo (jointime(microtime()) - $begintijd)." ";

ob_end_flush();

echo (jointime(microtime()) - $begintijd);
?>

Geeft steeds een iets ander resultaat, maar deze keer 0.00031101703643799 2.2508239746094.

Dat wil dus zeggen: van het begin van het uitvoeren door PHP tot ob_end_flush() gaat razendsnel, de ob_end_flush() kost meer dan 2 seconden.

zondag 10 februari 2002 17:54

Acties:

zondag 10 februari 2002 18:01

Software Architect

Werkt hier

Op zondag 10 februari 2002 17:52 schreef gvtulder het volgende:
Dat wil dus zeggen: van het begin van het uitvoeren door PHP tot ob_end_flush() gaat razendsnel, de ob_end_flush() kost meer dan 2 seconden.

Wat ik al dacht, het "van de server naar de client sturen" kost dus 2 seconden...

Als jij of je school geen snelle internet verbinding hebt/heeft is dat ook niet zo'n gekke waarde

Acties:

Topicstarter

Dat klopt niet helemaal. Volgens mij heeft de verwerking van het script door PHP niets te maken met de tijd die Apache er voor nodig heeft om het resultaat van dat script naar mij te sturen. Of heb ik dat fout? De tijd die je hier ziet is de tijd die PHP nodig heeft om het resultaat naar Apache te versturen, niet de tijd die het resultaat nodig heeft om bij mij te komen.

Bovendien zou wget op die server zelf dan een veel kortere tijd moeten laten zien, maar dat is niet zo. 0.000357985496521 1.4769719839096, dus nog altijd anderhalve seconde verwerkingstijd. Dat is een tijd die ik ook wel eens krijg, maar naar mijn idee nog steeds erg lang. Of denk ik dat het allemaal veel te snel kan?

zondag 10 februari 2002 18:07

Acties: