perl script onder apache trager dan op command-line?

[Arjen Haayman]

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 --

[robert]

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

[Arjen Haayman]

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 --

[robert]

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

[Edwin Martin]

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/

[Rene Pijlman]

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

[Arjen Haayman]

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 --

[Rene Pijlman]

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

[Arjen Haayman]

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.

[Rene Pijlman]

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

[Arjen Haayman]

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 --

[robert]

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

[Michiel de Roo]

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 ?

[robert]

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

[Daniel Tryba]

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

[robert]

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> 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.

Zo te zien is dat zo. Een andere mogelijkheid is dat de server de connectie
dichtgooit als alles verzonden is.

--
robert

[Arjen Haayman]

robert schreef:
> 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 :)
>

Inderdaad! Ik heb nu HTTP/1.0 ingesteld en het gaat veel sneller!
Misschien heb je zin om te vertellen wat het verschil is?

Arjen Haayman

[robert]

Arjen Haayman <ahaayman@deadspam.com>:
<snip>
> Inderdaad! Ik heb nu HTTP/1.0 ingesteld en het gaat veel sneller!
> Misschien heb je zin om te vertellen wat het verschil is?

Een nadeel van het oude HTTP protocol was dat de browser voor elk extern
element van een webpagina (plaatjes, externe stylesheets, externe
JS-scripts, enzovoort) een nieuwe verbinding met de webserver moest
opzetten, en juist zo'n nieuwe verbinding opzetten kost (relatief) veel
tijd.

Met de 1.1 versie is het mogelijk om meerdere requests (en responses)
binnen één 'sessie' met de server af te handelen. Een browser moet dan wel
weten wanneer de response van de server klaar is, voordat er weer een nieuw
request opgestuurd kan worden.

Meestal kan de browser dat bepalen aan de hand van de door de server
meegegeven Content-Length header; dat is in feite de manier van de server
om te zetten 'oké, er komt nu een hoeveelheid data naar je toe, en wel van
zus-en-zoveel bytes groot'. De browser leest die hoeveelheid bytes, en gaat
er dan van uit dat er weer een nieuw request gestuurd kan worden.

Bij CGI-scripts zit je alleen met het probleem dat de server de grootte
van de data over het algemeen niet kan bepalen, omdat het niet gaat om een
bestand (zoals een simpele HTML pagina of een plaatje) waar makkelijk de
grootte van bepaald kan worden.

En dus kan de server geen Content-Length meesturen (tenzij de server de
complete uitvoer van het CGI script eerst buffert en er dan de lengte van
bepaalt, maar dat kan potentieel problematisch zijn.

Kennelijk gaat Mozilla een bepaalde tijd zitten wachten voordat 'ie
doorheeft dat er geen uitvoer meer van de server komt, en tot die tijd laat
je browser niks zien (of hij laat de uitvoer niet volledig zien, ik weet
niet precies wat je specifieke klachten waren).

Als je 1.0 aanzet dan gooit de server na het opsturen van de uitvoer van
je script de verbinding dicht, en dat is voor Mozilla het teken dat de
response klaar is (zodat 'ie niet hoeft te gaan wachten).

Gebruik je misschien een oude versie van Mozilla? Want ik kan me niet
herinneren dat mijn Mozilla hetzelfde probleem heeft.

--
robert

[Arjen Haayman]

> Gebruik je misschien een oude versie van Mozilla? Want ik kan me niet
> herinneren dat mijn Mozilla hetzelfde probleem heeft.

neuh. Ik gebruik 1.6

Dus de oplossing is om de content-length mee te geven?
Ik zal eens kijken of ik dat voor elkaar krijg.
Overigens: waarom kan bij PHP wel de content-lenth worden meegegeven?
Dat zijn toch ook dynamische scripts waar run-time steeds meer content
bij kan komen?

Arjen Haayman

[robert]

Arjen Haayman <ahaayman@hotmail.com>:
>> Gebruik je misschien een oude versie van Mozilla? Want ik kan me niet
>> herinneren dat mijn Mozilla hetzelfde probleem heeft.
>
> neuh. Ik gebruik 1.6
>
> Dus de oplossing is om de content-length mee te geven?

Dat zou het probleem wel moeten oplossen, zou ik denken.

> Ik zal eens kijken of ik dat voor elkaar krijg.

Lastig, zeker vanuit een CGI omdat je pas na het genereren van de complete
uitvoer weet hoeveel data je gaat opsturen. Misschien dat Apache er een
mogelijkheid voor heeft, anders moet je aan de slag met outputbuffering
(wat in Perl overigens ook niet zo'n probleem is, daar bestaan AFAIK
modules voor).

> Overigens: waarom kan bij PHP wel de content-lenth worden meegegeven?

De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.

--
robert

[Daniel Tryba]

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Dus de oplossing is om de content-length mee te geven?
>
> Dat zou het probleem wel moeten oplossen, zou ik denken.

Geen persistent connections gebruiken in het probleem script:
'Connection: close'

> > Overigens: waarom kan bij PHP wel de content-lenth worden meegegeven?
>
> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.

Dat is natuurlijk ook moeilijk te weten bij dynamische paginas. Als je
die wilt meesturen zal je dat zelf moeten doen (door de hele output te
bufferen en als laatste nog snel even de content-length in de headers
proppen).

--

Daniel Tryba

[robert]

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.
>
> Dat is natuurlijk ook moeilijk te weten bij dynamische paginas.

Mijn webserver (mod_perl, Apache::ASP, XML en XSLT) stuurt ze netjes mee,
zonder dat ik er iets voor hoef te doen zelfs ;)

--
robert

[Daniel Tryba]

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> >> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.
> >
> > Dat is natuurlijk ook moeilijk te weten bij dynamische paginas.
>
> Mijn webserver (mod_perl, Apache::ASP, XML en XSLT) stuurt ze netjes mee,
> zonder dat ik er iets voor hoef te doen zelfs ;)

Je stuurt je pagina's dan ook gecompressed op. Als je dat aan Apache
overlaat heeft die de pagina al geheel gebuffered en weet dus ook de
content-length.

--

Daniel Tryba

[robert]

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>
>> >> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length
>> >> mee.
>> >
>> > Dat is natuurlijk ook moeilijk te weten bij dynamische paginas.
>>
>> Mijn webserver (mod_perl, Apache::ASP, XML en XSLT) stuurt ze netjes
>> mee, zonder dat ik er iets voor hoef te doen zelfs ;)
>
> Je stuurt je pagina's dan ook gecompressed op.

Alleen bij browsers die dat aankunnen, met het handje overgehaalde pagina's
hebben ook een Content-Length. Alhoewel mod_gzip misschien daar toch tussen
zit...

--
robert