Onderwerp: perl script onder apache trager dan op command-line?

Hallo,

Ik gebruik perl voor m'n CGI-scripts en ik merk steeds dat wanneer ik de
scripts via de browser gebruik, de response erg laag is. Het duurt echt
zo'n 4 a 5 seconden voordat ik antwoord krijg, terwijl als ik diezelfde
scripts vanaf de command-line start krijg ik onmiddelijk de HTML-code te
zien.

Weet iemand waar deze vertraging vandaan kan komen?

Ik gebruik ook DBI met MySQL in deze scripts.

P.S. Ik weet wel dat mod_perl sneller is dan CGI, maar ik verwacht
eigenlijk niet zo'n verschil in snelheid tussen Apache en command-line.

--
Arjen Haayman
-- cogito ergo bicyclo --

Arjen Haayman <ahaayman@deadspam.com>:
> Ik gebruik perl voor m'n CGI-scripts en ik merk steeds dat wanneer ik de
> scripts via de browser gebruik, de response erg laag is. Het duurt echt
> zo'n 4 a 5 seconden voordat ik antwoord krijg, terwijl als ik diezelfde
> scripts vanaf de command-line start krijg ik onmiddelijk de HTML-code te
> zien. Weet iemand waar deze vertraging vandaan kan komen?

Buffering van stdout wellicht. Probeer bovenaan je Perl-script eens het
volgende te zetten:

use IO::Handle;
STDOUT->autoflush();
STDERR->autoflush();

Daarnaast kan het zijn dat je Apache wat dingen doet, zoals het reverse-
lookupen van IP-adressen, die tijd kosten. Dat kan je in de config van
Apache uitzetten.

Of misschien werkt de communicatie met MySQL niet helemaal oke. Je script
zal als gebruiker 'nobody' worden uitgevoerd (ervan uitgaande dat je een
Unix-afgeleide gebruikt), daar moet je rekening mee houden in het toewijzen
van rechten.

--
robert

robert wrote:
> Buffering van stdout wellicht. Probeer bovenaan je Perl-script eens het
> volgende te zetten:
>
> use IO::Handle;
> STDOUT->autoflush();
> STDERR->autoflush();
Ga ik proberen.

>
> Daarnaast kan het zijn dat je Apache wat dingen doet, zoals het reverse-
> lookupen van IP-adressen, die tijd kosten. Dat kan je in de config van
> Apache uitzetten.
>
> Of misschien werkt de communicatie met MySQL niet helemaal oke. Je script
> zal als gebruiker 'nobody' worden uitgevoerd (ervan uitgaande dat je een
> Unix-afgeleide gebruikt), daar moet je rekening mee houden in het toewijzen
> van rechten.
>
Hoe kunnen rechten vertragend werken? Als het niet goed staat werkt het
toch helemaal niet?


--
Arjen Haayman
-- cogito ergo bicyclo --

Arjen Haayman <ahaayman@deadspam.com>:
> robert wrote:
>> Of misschien werkt de communicatie met MySQL niet helemaal oke. Je
>> script zal als gebruiker 'nobody' worden uitgevoerd (ervan uitgaande
>> dat je een Unix-afgeleide gebruikt), daar moet je rekening mee houden
>> in het toewijzen van rechten.
>
> Hoe kunnen rechten vertragend werken? Als het niet goed staat werkt het
> toch helemaal niet?

Weinig MySQL ervaring, dus ik deed maar een gok

--
robert

Arjen Haayman wrote:
> Hallo,
>
> Ik gebruik perl voor m'n CGI-scripts en ik merk steeds dat wanneer ik de
> scripts via de browser gebruik, de response erg laag is. Het duurt echt
> zo'n 4 a 5 seconden voordat ik antwoord krijg, terwijl als ik diezelfde
> scripts vanaf de command-line start krijg ik onmiddelijk de HTML-code te
> zien.
>
> Weet iemand waar deze vertraging vandaan kan komen?
>
> Ik gebruik ook DBI met MySQL in deze scripts.
>
> P.S. Ik weet wel dat mod_perl sneller is dan CGI, maar ik verwacht
> eigenlijk niet zo'n verschil in snelheid tussen Apache en command-line.

Probeer het eens met een Perl script met een enkel print-statement.

Dan zie je of het aan de script ligt of aan de Apache configuratie.

Als je jouw script op de prompt uitvoert, hoe lang duurt het dan
voor de prompt weer verschijnt. Je kunt wel al uitvoer zien, maar zolang
de prompt niet verschijnt, is het programma nog niet afgelopen en
wordt mogelijk de uitvoer niet verstuurd. In Perl is het wel in te
schakelen dat de uitvoer direct getoont wordt, met (als ik het me goed
herinner):

$|=1;

Groeten,
Edwin Martin.

--
http://www.bitstorm.org/

Arjen Haayman:
>Ik gebruik perl voor m'n CGI-scripts en ik merk steeds dat wanneer ik de
>scripts via de browser gebruik, de response erg laag is. Het duurt echt
>zo'n 4 a 5 seconden voordat ik antwoord krijg, terwijl als ik diezelfde
>scripts vanaf de command-line start krijg ik onmiddelijk de HTML-code te
>zien.
>
>Weet iemand waar deze vertraging vandaan kan komen?

Weet je zeker dat het script via CGI en de command line dezelfde
functionaliteit doorloopt?

Misschien bevat die via de command-line gegenereerde HTML-code alleen een
foutmelding wegens het ontbreken van de CGI-environment :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:

>
> Weet je zeker dat het script via CGI en de command line dezelfde
> functionaliteit doorloopt?
>
> Misschien bevat die via de command-line gegenereerde HTML-code alleen een
> foutmelding wegens het ontbreken van de CGI-environment :-)
>
Ja, duh

--
Arjen Haayman
-- cogito ergo bicyclo --

Arjen Haayman:
>Ja, duh

Dit betekent zeker: "Ja, dat was dom van mij. Dankjewel René!" :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote in message news:<gutf205bve5ehtlesvioqlliul2f2dbno4@4ax.com>. ..
> Arjen Haayman:
> >Ja, duh
>
> Dit betekent zeker: "Ja, dat was dom van mij. Dankjewel René!" :-)

Ik dacht meer aan: "Waar zie je me voor aan????"

Intussen krijg ik de vinger er niet echt achter. :-( Het is ook een
beetje moeilijk reproduceerbaar en die zin dat de respons soms best
wel aardig is...
Ik heb een beetje het gevoel dat m'n browser op een EOF zit te wachten
ofzo.
Ik zie bijvoorbeeld dat de titel al lang is ingevuld voordat de rest
verschijnt.

Arjen Haayman:
>Ik dacht meer aan: "Waar zie je me voor aan????"

Geen commentaar :-)

>Ik heb een beetje het gevoel dat m'n browser op een EOF zit te wachten
>ofzo.
>Ik zie bijvoorbeeld dat de titel al lang is ingevuld voordat de rest
>verschijnt.

Dit wil ook nog weleens het gevolg zijn van Nedstat-icoontje o.i.d. binnen
een table.

Voor een server-side effect kan ik zo 1-2-3 geen verklaring bedenken. Je
zou dan toch even wat timestamping moeten inbouwen om erachter te komen
waar de wachtttijd in zit.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:

> Voor een server-side effect kan ik zo 1-2-3 geen verklaring bedenken. Je
> zou dan toch even wat timestamping moeten inbouwen om erachter te komen
> waar de wachtttijd in zit.
>
Ik heb een vreemde ontdekking gedaan: het probleem speelt helemaal niet
als ik Internet Explorer gebruik. Normaal gebruik ik Mozilla. En het
heeft niets met rendering te maken.

Hoe zou dit nu aan de browser kunnen liggen?

--
Arjen Haayman
-- cogito ergo bicyclo --

Arjen Haayman <ahaayman@deadspam.com>:
> Rene Pijlman wrote:
>
>> Voor een server-side effect kan ik zo 1-2-3 geen verklaring
>> bedenken. Je zou dan toch even wat timestamping moeten inbouwen om
>> erachter te komen waar de wachtttijd in zit.
>
> Ik heb een vreemde ontdekking gedaan: het probleem speelt helemaal niet
> als ik Internet Explorer gebruik. Normaal gebruik ik Mozilla. En het
> heeft niets met rendering te maken.
>
> Hoe zou dit nu aan de browser kunnen liggen?

Het zou er mee te maken kunnen hebben dat Mozilla ingesteld staat op
HTTP/1.1 requests (Advanced > HTTP Networking), je webserver voor de
uitvoer van je script geen Content-Length berekent, en je browser blijft
wachten op nieuwe data van de webserver, die er nooit komt.

--
robert

robert wrote:
> Arjen Haayman <ahaayman@deadspam.com>:
> > Rene Pijlman wrote:
> >
> >> Voor een server-side effect kan ik zo 1-2-3 geen verklaring
> >> bedenken. Je zou dan toch even wat timestamping moeten inbouwen om
> >> erachter te komen waar de wachtttijd in zit.
> >
> > Ik heb een vreemde ontdekking gedaan: het probleem speelt helemaal niet
> > als ik Internet Explorer gebruik. Normaal gebruik ik Mozilla. En het
> > heeft niets met rendering te maken.
> >
> > Hoe zou dit nu aan de browser kunnen liggen?
>
> Het zou er mee te maken kunnen hebben dat Mozilla ingesteld staat op
> HTTP/1.1 requests (Advanced > HTTP Networking), je webserver voor de
> uitvoer van je script geen Content-Length berekent, en je browser blijft
> wachten op nieuwe data van de webserver, die er nooit komt.
>

Kun je je webserver zo instellen dat ie dat wel gaat berekenen ?

Michiel de Roo <michiel@mderooPUNTNL>:
> robert wrote:
>> Het zou er mee te maken kunnen hebben dat Mozilla ingesteld staat op
>> HTTP/1.1 requests (Advanced > HTTP Networking), je webserver voor de
>> uitvoer van je script geen Content-Length berekent, en je browser
>> blijft wachten op nieuwe data van de webserver, die er nooit komt.
>
> Kun je je webserver zo instellen dat ie dat wel gaat berekenen ?

Geen idee eigenlijk, ik maak al jaren geen gebruik meer van losse CGI
scripts. Zo te zien doet PHP ook niet aan content-length's, dus het is
misschien een idee om eerst eens met de instellingen van Mozilla te spelen
om te zien of het daar uberhaupt wel aan ligt

--
robert

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
[http/1.1 en ontbrekende contentlength]
> > Kun je je webserver zo instellen dat ie dat wel gaat berekenen ?
>
> Geen idee eigenlijk, ik maak al jaren geen gebruik meer van losse CGI
> scripts. Zo te zien doet PHP ook niet aan content-length's, dus het is
> misschien een idee om eerst eens met de instellingen van Mozilla te spelen
> om te zien of het daar uberhaupt wel aan ligt

Hmmmm, wat zegt de rfc (2616) over dit geval? Ik zou overigens
verwachten dat indien een browser een 1.1 request doet en een script
geen content-length meegeeft de zut chunked zou worden verstuurd door de
webserver.

--

Daniel Tryba