OVH Cloud OVH Cloud

perlcc +DBI +CGI

9 réponses
Avatar
Laurent Bize
J'ai écris un script CGI qui se connecte sur une base mysql.

Pour améliorer les performances coté serveur, j'ai essayé perlcc
sur mon script, mais problème :
- Lors de la compilation j'ai le warning suivant :
"pccoWcZr.c:46059: AVERTISSEMENT: constante décimale est tellement grande qu'elle est non signée"
Mais l'executable est bien créé et ne produit pas
d'erreur de segmentation.
- Lors de l'execution :
Tout se déroule comme il faut (génération de
l'en-tête, etc) jusqu'à la connexion :
"Undefined subroutine &DBI::dr::connect called at /usr/lib/perl5/DBI.pm line 575."
"Undefined subroutine &DBI::dr::disconnect_all called at /usr/lib/perl5/DBI.pm line 642."
"END failed--call queue aborted."
Après cette erreur le pied de page est tout de même bien créé.

Avez-vous une idée de ce qui se passe ?

L'en tête du script perl :
#!/usr/bin/perl -w
use strict;
use CGI qw( -nosticky :standard);
use CGI::Carp qw/fatalsToBrowser/;
use DBI;
use DBI::DBD;

La ligne de commande perlcc :
perlcc -v -L /usr/lib/perl5/auto/DBI -I /usr/lib/perl5/auto/DBI -o test test.pl

Laurent

9 réponses

Avatar
root
On Thu, 07 Aug 2003 11:13:48 +0200, Laurent Bize wrote:

J'ai écris un script CGI qui se connecte sur une base mysql.

Pour améliorer les performances coté serveur, j'ai essayé perlcc
sur mon script, mais problème :
- Lors de la compilation j'ai le warning suivant :
"pccoWcZr.c:46059: AVERTISSEMENT: constante décimale est tellement grande qu'elle est non signée"
Mais l'executable est bien créé et ne produit pas
d'erreur de segmentation.
- Lors de l'execution :
Tout se déroule comme il faut (génération de
l'en-tête, etc) jusqu'à la connexion :
"Undefined subroutine &DBI::dr::connect called at /usr/lib/perl5/DBI.pm line 575."
"Undefined subroutine &DBI::dr::disconnect_all called at /usr/lib/perl5/DBI.pm line 642."
"END failed--call queue aborted."
Après cette erreur le pied de page est tout de même bien créé.

Avez-vous une idée de ce qui se passe ?



Je vais répondre a coté ... :)

Mais je ne pense pas que la "compilation" améliorera de beaucoup les
performances ...
(en gros, la compilation ne fait que "linker" ton script avec la librairie
de l'interpreteur Perl ...)

Perso, je regarderais plutôt vers une adaptation en mod_perl (on évite le
lancement de l'interpreteur perl/d'un programme à chaque invocation du
script) et avec l'utilisation de connections persistentes avec la BD ...

Avatar
Laurent Bize
Je vais répondre a coté ... :)

Mais je ne pense pas que la "compilation" améliorera de beaucoup les
performances ...
(en gros, la compilation ne fait que "linker" ton script avec la librairie
de l'interpreteur Perl ...)

Perso, je regarderais plutôt vers une adaptation en mod_perl (on évite le
lancement de l'interpreteur perl/d'un programme à chaque invocation du
script) et avec l'utilisation de connections persistentes avec la BD ...


Merci au root Toulousain :)

Laurent

Avatar
Laurent Bize
root a écrit:
On Thu, 07 Aug 2003 11:13:48 +0200, Laurent Bize wrote:


J'ai écris un script CGI qui se connecte sur une base mysql.

Pour améliorer les performances coté serveur, j'ai essayé perlcc
sur mon script, mais problème :
- Lors de la compilation j'ai le warning suivant :
"pccoWcZr.c:46059: AVERTISSEMENT: constante décimale est tellement grande qu'elle est non signée"
Mais l'executable est bien créé et ne produit pas
d'erreur de segmentation.
- Lors de l'execution :
Tout se déroule comme il faut (génération de
l'en-tête, etc) jusqu'à la connexion :
"Undefined subroutine &DBI::dr::connect called at /usr/lib/perl5/DBI.pm line 575."
"Undefined subroutine &DBI::dr::disconnect_all called at /usr/lib/perl5/DBI.pm line 642."
"END failed--call queue aborted."
Après cette erreur le pied de page est tout de même bien créé.

Avez-vous une idée de ce qui se passe ?




Je vais répondre a coté ... :)

Mais je ne pense pas que la "compilation" améliorera de beaucoup les
performances ...
(en gros, la compilation ne fait que "linker" ton script avec la librairie
de l'interpreteur Perl ...)

Perso, je regarderais plutôt vers une adaptation en mod_perl (on évite le
lancement de l'interpreteur perl/d'un programme à chaque invocation du
script)


Ceci est déjà fait (après vérification dans le httpd.conf)

et avec l'utilisation de connections persistentes avec la BD ...


En cours de test et de bench....

Laurent


Avatar
Laurent Bize
et avec l'utilisation de connections persistentes avec la BD ...



En cours de test et de bench....


Le gain est intéressant :)
Merci.

Laurent


Avatar
Emmanuel Florac
Dans article ,
disait...

Perso, je regarderais plutôt vers une adaptation en mod_perl (on évite le
lancement de l'interpreteur perl/d'un programme à chaque invocation du
script) et avec l'utilisation de connections persistentes avec la BD ...


Heu, ça amrche les connexions persistantes en perl? C'est vraiment
utile?

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Avatar
root
On Thu, 07 Aug 2003 18:53:04 +0200, Emmanuel Florac wrote:

Dans article ,
disait...

Perso, je regarderais plutôt vers une adaptation en mod_perl (on
évite le lancement de l'interpreteur perl/d'un programme à chaque
invocation du script) et avec l'utilisation de connections
persistentes avec la BD ...


Heu, ça amrche les connexions persistantes en perl?


Si on utilise mod_perl oui :
- http://perl.apache.org/docs/1.0/guide/performance.html#Persistent_DB_Connections
- http://search.cpan.org/author/ABH/Apache-DBI-0.91/DBI.pm

C'est vraiment utile?


Tout comme l'utilisation de mod_perl évite de lancer un interpréteur
perl à chaque requête sur le script, le système de connexion
persistante permet de ne pas avoir à ouvrir la connexion avec la BD à
chaque utilisation du script. On ouvre la connexion lors du premier
appel au script par exemple (ou au démarrage du serveur) ensuite lors
des prochains appels, la connexion est déjà ouverte et utilisable ...


Avatar
Paul GABORIT
À (at) Thu, 7 Aug 2003 18:53:04 +0200,
Emmanuel Florac écrivait (wrote):
Dans article ,
disait...

Perso, je regarderais plutôt vers une adaptation en mod_perl (on évite le
lancement de l'interpreteur perl/d'un programme à chaque invocation du
script) et avec l'utilisation de connections persistentes avec la BD ...


Heu, ça amrche les connexions persistantes en perl? C'est vraiment
utile?


Ça marche si le script Perl lui-même est persistant ;-) C'est le cas, si on
utilise mod_perl (mais tout n'est pas toujours facile à maitriser sous
mod_perl (*)) ou si on utilise FastCGI (c'est beaucoup plus simple à
utiliser/installer que mod_perl).

Est-ce vraiment utile ? Là, ça dépend du SGBD et de la charge de la
machine. Avec mysql et une machine qui n'a que cela à faire, une connexion est
très rapide donc le gain est faible. Avec Oracle, une machine qui fait plein
d'autres choses et une authentification via LDAP sur un réseau très
chargé... alors là, le temps de connexion à Oracle peut atteindre la seconde
voire plus. Donc ça devient très très intéressant !

(*) en particulier, qu'est-ce qui est persistant et comment interragisent les
différents instances du serveur lui-même.

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail


Avatar
Emmanuel Florac
Dans article ,
disait...

(*) en particulier, qu'est-ce qui est persistant et comment interragisent les
différents instances du serveur lui-même.



Ben oui, c'est ça que je ne comprends pas trop... Ah moins que le script
ne soit le serveur http lui-même, je ne vois pas comment la connexion
peut être persistante de façon fiable...

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Avatar
Paul GABORIT
À (at) Fri, 8 Aug 2003 12:02:58 +0200,
Emmanuel Florac écrivait (wrote):
Dans article ,
disait...

(*) en particulier, qu'est-ce qui est persistant et comment interragisent
les différents instances du serveur lui-même.



Ben oui, c'est ça que je ne comprends pas trop... Ah moins que le script
ne soit le serveur http lui-même, je ne vois pas comment la connexion
peut être persistante de façon fiable...


Avec mod_perl, l'interpréteur Perl est dans le serveur HTTP. Les scripts
tournent donc dans le serveur lui-même. Cela leur permet de faire plein de
choses tant au lancement du serveur qu'à chacune des étapes du traitement
d'une requête par le serveur. C'est surtout en cela que mod_perl est BEAUCOUP
plus puissant qu'un simple CGI.

L'une des utilisations possibles est donc la connexion permanente à un SGBD
(de la durée de vie du processus 'httpd'). Là où ça se corse, c'est que le
serveur lui-même est multi-processus. D'où quelques suprises parfois (au début
en tous cas ;-).

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail