---

Hej alle!

Jeg anvender med jævne mellemrum perls DBI i mine CGI-scripts til at tilgå
min PostgreSQL database. Det irriterer mig at DBI-modulet er så tungt at
initalisere..

Dette super-simple script:

--- script start ---

#!/bin/perl
use DBI;

--- script slut ---

tager Apache hele 600 msek. at eksekvere på min (noget langsomme, men
alligevel..) computer. Dette er et problem idet performance på webserveren
falder drastisk når der er "run" på CGI-scriptsene.

Er der nogen som har gode ideer til hvordan dette kan speedes op? Hvad er
det i DBI der tager så lang tid at initalisere? Der bruges faktisk længere
tid i den use-linie end der gør ved at oprette connection og eksekvere selve
forespørgslen..! Hvis ikke det er muligt at undgå dette store tidsforbrug,
er der så andre måder at connecte til postgresql som er hurtigere og
anbefalelsesværdige?

--
Mvh.
Thomas Holmgren

---

On 2003-11-01, Thomas Holmgren <thm@regnecentralen.dk> wrote:
>
> tager Apache hele 600 msek. at eksekvere på min (noget langsomme, men
> alligevel..) computer. Dette er et problem idet performance på webserveren
> falder drastisk når der er "run" på CGI-scriptsene.

Det er tungt at compile dit script og DBI hver gang. CGI er elendigt til
high-performance ting. Kig på FastCGI: http://www.fastcgi.com/ og
modperl: http://perl.apache.org/ (hvis du bruger Apache)

FastCGI er "blot" en måde at holde scripts compilede i hukommelsen, mens
modperl er en integration af Perl i Apache med fuld adgang til Apaches
API (der bl.a. holder compilet perl-kode i hukommelsen).

--
Andreas Plesner Jacobsen | Chaos is King and Magic is loose in the world.

---

Andreas Plesner Jacobsen <apj@daarligstil.dk> writes:

> On 2003-11-01, Thomas Holmgren <thm@regnecentralen.dk> wrote:
>>
>> tager Apache hele 600 msek. at eksekvere på min (noget langsomme, men
>> alligevel..) computer. Dette er et problem idet performance på webserveren
>> falder drastisk når der er "run" på CGI-scriptsene.
>
> Det er tungt at compile dit script og DBI hver gang. CGI er elendigt til
> high-performance ting. Kig på FastCGI: http://www.fastcgi.com/ og
> modperl: http://perl.apache.org/ (hvis du bruger Apache)
>
> FastCGI er "blot" en måde at holde scripts compilede i hukommelsen, mens
> modperl er en integration af Perl i Apache med fuld adgang til Apaches
> API (der bl.a. holder compilet perl-kode i hukommelsen).

Det muligør det også at holde database forbindelser åbne =>
Apache::DBI.
Du kan også prøve 'use DBI qw(<de funktioner du skal bruge>)'. Så
importerer den ikke alle funktioner.


--
Mvh|Regards, Lars
Graduate student
Department of Computer Science, University of Copenhagen

---

Thomas Holmgren wrote:
> --- script start ---
>
> #!/bin/perl
> use DBI;
>
> --- script slut ---
>
> tager Apache hele 600 msek. at eksekvere på min (noget langsomme, men
> alligevel..) computer. Dette er et problem idet performance på webserveren
> falder drastisk når der er "run" på CGI-scriptsene.

Har du prøvet at sammenligne med dette fine script:

--- begynd --
#!/bin/perl
1;
--- slut --

Jeg kunne forestille mig at det næsten tager lige så lang tid at
eksekvere - idet problemet er at ved et CGI-script skal der startes en
hel ny perl-process op..

Som allerede nævnt kan du formentligt få en mange gange bedre
performance ved at bruge mod_perl eller lign...

--
Mvh. Nezar Nielsen
http://fez.dk

---

On Wed, 05 Nov 2003 18:36:27 +0100, Nezar wrote:

>> Nei. Å laste DBI-modulen _tar_ tid. Akkurat hvor lang tid det
>> tar, avhenger selvfølgelig av hvor raskt datamaskin man har.

> Men det tager vel ikke synderligt lang tid i forhold til at skulle
> starte perl...(skulle jeg tro).

En lille helt uvidenskabelig test:

$ time for i in $(seq 1 2000); do perl -e ""; done

real 0m7.996s
user 0m3.670s
sys 0m4.320s

og

$ time for i in $(seq 1 2000); do perl -MDBI -e ""; done

real 2m18.032s
user 2m4.780s
sys 0m13.160s

8 sekunder tog det at starte perl 2000 gange på min maskine, mens det
tog 2 minutter og 18 at starte perl med DBI. Det virker som om DBI
dominerer?


Mvh.

--
Det største problem ved usenet er, at dem man har Adam Sjøgren
i sin kill-file hele tiden skifter From:-linie asjo@koldfront.dk

---

Adam Sjøgren wrote:

> 8 sekunder tog det at starte perl 2000 gange på min maskine, mens det
> tog 2 minutter og 18 at starte perl med DBI. Det virker som om DBI
> dominerer?

Avs. Jeg havde sku ikke regnet med at det var så galt.

--
Mvh. Nezar Nielsen
http://fez.dk

---

spamtrap@koldfront.dk (Adam Sjøgren) writes:

> On Wed, 05 Nov 2003 18:36:27 +0100, Nezar wrote:
>
> >> Nei. Å laste DBI-modulen _tar_ tid. Akkurat hvor lang tid det
> >> tar, avhenger selvfølgelig av hvor raskt datamaskin man har.
>
> > Men det tager vel ikke synderligt lang tid i forhold til at skulle
> > starte perl...(skulle jeg tro).
>
> En lille helt uvidenskabelig test:
>
> $ time for i in $(seq 1 2000); do perl -e ""; done
>
> real 0m7.996s
ca. 4 msek pr opstart - ikke ilde....
> og
>
> $ time for i in $(seq 1 2000); do perl -MDBI -e ""; done
>
> real 2m18.032s
ca. 69 msek pr opstart, dvs 65 msek for at indlæse og fortolke DBI.pm
- slet ikke ilde.

Jeg fortsatte din lille serie af eksperimenter - DBI er jo kun
interessant hvis man agter at benytte en database.
Og *DET* tager tid.

Dette lille program:
use DBI;
use Benchmark qw(:all);

# for at fjerne evt opstart-tid
my $dbh=DBI->connect("dbi:Ingres:htdb");
$dbh->disconnect;

timethis(100, '$dbh=DBI->connect("dbi:Ingres:htdb");
$dbh->disconnect;');
Giver dette resultat:
timethis 100: 73 wallclock secs ( 0.05 usr + 0.03 sys = 0.08 CPU) @ 1250.00/s (n=100)
(warning: too few iterations for a reliable count)
Dvs ca 730 msek for at connect'e og disconnect'e. I det spil
forsvinder 69 msek for at læse DBI.pm fuldstændig.

--
Henrik Tougaard
- Bad spellers og the world: UNTIE.

---

Adam Sjøgren wrote:

> On Wed, 05 Nov 2003 18:36:27 +0100, Nezar wrote:
>
[clip]
>
> 8 sekunder tog det at starte perl 2000 gange på min maskine, mens det
> tog 2 minutter og 18 at starte perl med DBI. Det virker som om DBI
> dominerer?
>
>
> Mvh.
>


Det er defor at man kan få mod_perl til at preloade moduler med
direktivet PerlModule i httpd.conf
f.eks.

PerlModule CGI DBI

for at preloade CGI og DBI modulet.

Med hensyn til at reconnecte til database så tager det også lang tid
(som diskturet længere nede i tråden). Der kan DBI's connect_cached()
være en fordel.

--
Robert Hjertmann Christiansen
Technical University of Denmark

---

---

---

On 06 Nov 2003 16:53:50 +0100, Henrik wrote:

> Jeg fortsatte din lille serie af eksperimenter - DBI er jo kun
> interessant hvis man agter at benytte en database.

Tjah, alt efter hvad man starter perl op for at gøre uden DBI kan det
jo også tage tid.

> Giver dette resultat: timethis 100: 73 wallclock secs ( 0.05 usr +
> 0.03 sys = 0.08 CPU) @ 1250.00/s (n=100) (warning: too few
> iterations for a reliable count)

73 sekunder?!

Jeg får 8 sekunder for 1000 forbindelser til Postgresql og 1 sekund
for 2000 til MySQL med en udgave af dit program der tager DSN og antal
iterationer på kommandolinien (på en P4 2.4Hz).

En af delene lyder langt ude, men hvilken?


Mvh.

--
"Mercurychrome - Waitin', when the wound's scraped raw Adam Sjøgren
Bones... - The biggest stitches that you ever wore" asjo@koldfront.dk

---

spamtrap@koldfront.dk (Adam Sjøgren) writes:

> On 06 Nov 2003 16:53:50 +0100, Henrik wrote:
>
> > Jeg fortsatte din lille serie af eksperimenter - DBI er jo kun
> > interessant hvis man agter at benytte en database.
>
> Tjah, alt efter hvad man starter perl op for at gøre uden DBI kan det
> jo også tage tid.
>
> > Giver dette resultat: timethis 100: 73 wallclock secs ( 0.05 usr +
> > 0.03 sys = 0.08 CPU) @ 1250.00/s (n=100) (warning: too few
> > iterations for a reliable count)
>
> 73 sekunder?!
>
> Jeg får 8 sekunder for 1000 forbindelser til Postgresql og 1 sekund
> for 2000 til MySQL med en udgave af dit program der tager DSN og antal
> iterationer på kommandolinien (på en P4 2.4Hz).
>
> En af delene lyder langt ude, men hvilken?
>
Ingen! De er nok begge rigtige.

Ingres er optimeret til at tingene går hurtigt når man har fået
forbindelse, mens det at få forbindelse tager *laaaaang* tid.

MySQL og Postgres er lavet til hurtige forbindelser (og hurtige
operationer under visse omstændigheder).

Det koster noget at få et "rigtigt" database system i gang, med
transaktioner, queryoptimizer osv.

At oprette forbindelse til Oracle tager vist nogenlunde samme tid -
sådan +/- en træskolængde.

DBI har samme filosofi (nok ikke mindst fordi Tim Bunce skrev
DBD::Oracle parallelt med DBI) - det tager tid at initiere, men det
går stærkt når man først er i gang.

--
Henrik

---

On Thu, 06 Nov 2003 18:14:01 +0100, Tore wrote:

>> timethis 100: 73 wallclock secs ( 0.05 usr + 0.03 sys = 0.08 CPU) @
>> 1250.00/s (n=100) (warning: too few iterations for a reliable
>> count)

> Dette er galt. Som Benchmark.pm forteller deg så er ikke dette
> resultatet til å stole på, ettersom du har angitt for få
> iterasjoner.

> Prøv med f.eks. 5.000 iterasjoner.

Da 100 iterationer tager 73 sekunder, så skal hans maskine vel stå og
kværne i op mod en time for 5000...


Mvh.

--
"Mercurychrome - Waitin', when the wound's scraped raw Adam Sjøgren
Bones... - The biggest stitches that you ever wore" asjo@koldfront.dk

---

On 06 Nov 2003 21:39:07 +0100, Henrik wrote:

> Ingres er optimeret til at tingene går hurtigt når man har fået
> forbindelse, mens det at få forbindelse tager *laaaaang* tid.

Absurd lang tid, synes jeg det virker som om?

Jeg kunne forstå hvis det var en faktor 10 eller 20, men faktor
90-1400 virker lidt voldsomt - men det kommer selvfølgelig også an på
hvor hurtig den maskine du tester på er.


Mvh.

--
"Mercurychrome - Waitin', when the wound's scraped raw Adam Sjøgren
Bones... - The biggest stitches that you ever wore" asjo@koldfront.dk

---

---

On 2003-11-06, Thomas Holmgren <thm@cs.auc.dk> wrote:
>
> Tak for tippet :) Jeg bruger rigtignok apache, og jeg kan se at mod_perl
> er installeret (rpm på min linux-box). Men.. hvordan kan jeg teste om
> apache rent faktisk bruger mod_perl og ikke den eksterne perl fortolker?

Udgangspunkt: Det gør den ikke. For at få den til det: Læs
http://perl.apache.org/

> Det undrer mig at man (iflg. mod_perl-dokumentation) stadig skal angive
> stien til perl-fortolkeren (#!/usr/bin/perl)?? Hvorfor skal apache vide
> hvor dén ligger, hvis mod_perl står for fortolkningen af scriptet?!

Det skal den heller ikke med eksempelvis mod_perl, men husk også at perl
selv kigger på shebang-linjen for at finde de switche den skal bruge.

--
Andreas Plesner Jacobsen | Try `stty 0' -- it works much better.