Soit un logiciel métier sous licence libre basé sur une plateforme
Linux-Apache-mySQL-Perl (mais pas mod-Perl) installé sur une plateforme
mandrake 9.2 et un athlon 1500+ qui fait à la fois serveur et client.
mySQL étant bien configuré et n'étant pas la source du problème.
L'affichage de certaines pages demande un délai sensible, donc trop long (je
parle là de <2 secondes. Disons que c'est pas immédiat).
Comment faire pour pister l'origine du problème ?
Je vois les possibilités suivantes :
* temps de compilation du script Perl+ des bib du cpan (MARC::Record,
NET::Z3950) + des bib "maisons" (pour environ 150ko de script -hors
packages cpan-)
* temps d'exécution du script (une imbrication de boucles qui ferait 100 000
fois un truc alors qu'on pourrait optimiser)
* erreur de conception dans la base (j'ai bien cherché, je ne pense pas que
ce soit ça. D'autant que le pb est le même avec une base quasi vide et une
base très chargée)
* temps de rendu de mozilla sur le poste client (sachant que le HTML généré
est "simple". Et sur les pages avec peu de traitement, le délai est
nettement moindre)
* c'est la mandrake 9.2 / Apache 2.0 qui sont mal compilés ou je sais pas
trop quoi d'autre.
Il y en a peut être d'autres.
Et il y a peut être des outils simples à mettre en oeuvre pour tracer
certains éléments ?
Voire des solutions pour accélérer le tout (je connais déjà mod-perl et
fast::cgi, mais on n'a pas essayé)
Sur un P3-800MHz, c'est quasi inutilisable.
--
Paul, projet http://www.koha-fr.org
Essaie de faire tourner ton script sous SpeedyCGI: http://www.daemoninc.com/SpeedyCGI/
apache2 n'a pas l'air d'aimer : Cannot load /etc/httpd/2.0/modules/mod_speedycgi.so into server: /etc/httpd/2.0/modules/mod_speedycgi.so: undefined symbol: ap_suexec_enabled
Essaie de compiler apache1 avec le support mod_perl...
C'est relativement facile:
http://take23.org/intro/index.xml/1#1
Une fois que tu as fait ca, utiliser mod_perl est plutot simple. Au lieu d'avoir quelque chose comme ca:
Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none
Tu as quelque chose comme ca:
SetHandler perl-script # ceci PerlHandler Apache::Registry # est pour PerlSendHeader On # mod_perl Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none
Ensuite il y a ce main::build_tabs qui a l'air de prendre pas mal de temps... elle fait quoi cette fonction?
C'est le coeur du script. Ca ne me choque pas qu'elle soit longue : elle lit des tables de hachage, elle remplit des arrays, qui sont passés à HTML::Template ensuite... avec plein de boucles et de conditions. Elle utilise aussi un objet MARC::Record (truc spécial/norme pour les bibliothèques)
Peut-etre, essaie de decouper cette fonction en sous-fonction, et lance DProf dessus, tu t'apercevras peut-etre qu'une des sous-fonction prends plus de temps qu'elle ne devrait ou peut etre cacheable par exemple.
Quand a HTML::Template, je suis sur que tu peux trouver plus rapide comme moteur de template...
<pub-gratuite> Essaie donc Petal: http://search.cpan.org/~jhiver/Petal/lib/Petal.pm </pub-gratuite>
for (1..50) { main() }; # fais la meme chose 50 fois # pour rendre les temps de compil negligeables
C'est une bonne idée : Total Elapsed Time = 24.85507 Seconds User+System Time = 16.95507 Seconds soit <0,5 secondes par passage. On doit pouvoir optimiser quelques petites choses...
Et DProf donne quoi sur cette execution?
Essaie de diriger l'output de ton script vers >/dev/null, voire si c'est pas ton xterm qui fait goulot d'etranglement.
Total Elapsed Time = 21.75507 Seconds User+System Time = 16.44507 Seconds on ne gagne pas grand chose.
Je ne vois pas ce qui se passe.
(je précise que le subfield_is_koha_internal_p appelé 16860 fois ne fait RIEN au niveau SQL. C'est une bète fonction booléenne, qu'on aurait même pu éviter de définir, probablement).
Qui prend presque 7% du temps total d'execution. Inline?
on progresse doucement : Total Elapsed Time = 19.26061 Seconds User+System Time = 15.68061 Seconds
Une petite seconde... pas terrible mais c'est mieux que rien :)
En conclusion : De toutes manières, il y a un peu tout qui se cumule : * une compilation du script longuette.
mod_perl + Apache::Registry elimine ca.
* le temps du fork...
mod_perl + Apache::Registry elimine ca.
* l'exécution, avec des calculs compliqués.
Voire si tu peux optimiser / cacher certaines fonctions.
* le temps de rendu. J'ai négligé de dire que le HTML généré faisait 74ko, ce qui est quand même pas rien ! (un masque de saisie avec une cinquantaine de champs/listes..., sur 10 onglets qui s'affichent et cachent)
Oui mais ca ca n'a rien a voir avec ton serveur.
* le temps de "fabrication" des polices de caractères. Si je prends un mozilla sans support xfs, c'est plus rapide !
Voire ci-dessus.
Essaie de faire tourner ton script sous SpeedyCGI:
http://www.daemoninc.com/SpeedyCGI/
apache2 n'a pas l'air d'aimer :
Cannot load /etc/httpd/2.0/modules/mod_speedycgi.so into server:
/etc/httpd/2.0/modules/mod_speedycgi.so: undefined symbol:
ap_suexec_enabled
Essaie de compiler apache1 avec le support mod_perl...
C'est relativement facile:
http://take23.org/intro/index.xml/1#1
Une fois que tu as fait ca, utiliser mod_perl est plutot simple. Au lieu
d'avoir quelque chose comme ca:
Options ExecCGI
AddHandler cgi-script .cgi
order allow,deny
allow from all
AllowOverride none
Tu as quelque chose comme ca:
SetHandler perl-script # ceci
PerlHandler Apache::Registry # est pour
PerlSendHeader On # mod_perl
Options ExecCGI
AddHandler cgi-script .cgi
order allow,deny
allow from all
AllowOverride none
Ensuite il y a ce main::build_tabs qui a l'air de prendre pas mal de
temps... elle fait quoi cette fonction?
C'est le coeur du script. Ca ne me choque pas qu'elle soit longue : elle lit
des tables de hachage, elle remplit des arrays, qui sont passés à
HTML::Template ensuite...
avec plein de boucles et de conditions.
Elle utilise aussi un objet MARC::Record (truc spécial/norme pour les
bibliothèques)
Peut-etre, essaie de decouper cette fonction en sous-fonction, et lance
DProf dessus, tu t'apercevras peut-etre qu'une des sous-fonction prends
plus de temps qu'elle ne devrait ou peut etre cacheable par exemple.
Quand a HTML::Template, je suis sur que tu peux trouver plus rapide
comme moteur de template...
<pub-gratuite>
Essaie donc Petal:
http://search.cpan.org/~jhiver/Petal/lib/Petal.pm
</pub-gratuite>
for (1..50) { main() }; # fais la meme chose 50 fois
# pour rendre les temps de compil negligeables
C'est une bonne idée :
Total Elapsed Time = 24.85507 Seconds
User+System Time = 16.95507 Seconds
soit <0,5 secondes par passage. On doit pouvoir optimiser quelques petites
choses...
Et DProf donne quoi sur cette execution?
Essaie de diriger l'output de ton script vers >/dev/null, voire si c'est
pas ton xterm qui fait goulot d'etranglement.
Total Elapsed Time = 21.75507 Seconds
User+System Time = 16.44507 Seconds
on ne gagne pas grand chose.
Je ne vois pas ce qui se passe.
(je précise que le subfield_is_koha_internal_p appelé 16860 fois ne fait
RIEN au niveau SQL. C'est une bète fonction booléenne, qu'on aurait même
pu éviter de définir, probablement).
Qui prend presque 7% du temps total d'execution. Inline?
on progresse doucement :
Total Elapsed Time = 19.26061 Seconds
User+System Time = 15.68061 Seconds
Une petite seconde... pas terrible mais c'est mieux que rien :)
En conclusion :
De toutes manières, il y a un peu tout qui se cumule :
* une compilation du script longuette.
mod_perl + Apache::Registry elimine ca.
* le temps du fork...
mod_perl + Apache::Registry elimine ca.
* l'exécution, avec des calculs compliqués.
Voire si tu peux optimiser / cacher certaines fonctions.
* le temps de rendu. J'ai négligé de dire que le HTML généré faisait 74ko,
ce qui est quand même pas rien ! (un masque de saisie avec une cinquantaine
de champs/listes..., sur 10 onglets qui s'affichent et cachent)
Oui mais ca ca n'a rien a voir avec ton serveur.
* le temps de "fabrication" des polices de caractères. Si je prends un
mozilla sans support xfs, c'est plus rapide !
Essaie de faire tourner ton script sous SpeedyCGI: http://www.daemoninc.com/SpeedyCGI/
apache2 n'a pas l'air d'aimer : Cannot load /etc/httpd/2.0/modules/mod_speedycgi.so into server: /etc/httpd/2.0/modules/mod_speedycgi.so: undefined symbol: ap_suexec_enabled
Essaie de compiler apache1 avec le support mod_perl...
C'est relativement facile:
http://take23.org/intro/index.xml/1#1
Une fois que tu as fait ca, utiliser mod_perl est plutot simple. Au lieu d'avoir quelque chose comme ca:
Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none
Tu as quelque chose comme ca:
SetHandler perl-script # ceci PerlHandler Apache::Registry # est pour PerlSendHeader On # mod_perl Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none
Ensuite il y a ce main::build_tabs qui a l'air de prendre pas mal de temps... elle fait quoi cette fonction?
C'est le coeur du script. Ca ne me choque pas qu'elle soit longue : elle lit des tables de hachage, elle remplit des arrays, qui sont passés à HTML::Template ensuite... avec plein de boucles et de conditions. Elle utilise aussi un objet MARC::Record (truc spécial/norme pour les bibliothèques)
Peut-etre, essaie de decouper cette fonction en sous-fonction, et lance DProf dessus, tu t'apercevras peut-etre qu'une des sous-fonction prends plus de temps qu'elle ne devrait ou peut etre cacheable par exemple.
Quand a HTML::Template, je suis sur que tu peux trouver plus rapide comme moteur de template...
<pub-gratuite> Essaie donc Petal: http://search.cpan.org/~jhiver/Petal/lib/Petal.pm </pub-gratuite>
for (1..50) { main() }; # fais la meme chose 50 fois # pour rendre les temps de compil negligeables
C'est une bonne idée : Total Elapsed Time = 24.85507 Seconds User+System Time = 16.95507 Seconds soit <0,5 secondes par passage. On doit pouvoir optimiser quelques petites choses...
Et DProf donne quoi sur cette execution?
Essaie de diriger l'output de ton script vers >/dev/null, voire si c'est pas ton xterm qui fait goulot d'etranglement.
Total Elapsed Time = 21.75507 Seconds User+System Time = 16.44507 Seconds on ne gagne pas grand chose.
Je ne vois pas ce qui se passe.
(je précise que le subfield_is_koha_internal_p appelé 16860 fois ne fait RIEN au niveau SQL. C'est une bète fonction booléenne, qu'on aurait même pu éviter de définir, probablement).
Qui prend presque 7% du temps total d'execution. Inline?
on progresse doucement : Total Elapsed Time = 19.26061 Seconds User+System Time = 15.68061 Seconds
Une petite seconde... pas terrible mais c'est mieux que rien :)
En conclusion : De toutes manières, il y a un peu tout qui se cumule : * une compilation du script longuette.
mod_perl + Apache::Registry elimine ca.
* le temps du fork...
mod_perl + Apache::Registry elimine ca.
* l'exécution, avec des calculs compliqués.
Voire si tu peux optimiser / cacher certaines fonctions.
* le temps de rendu. J'ai négligé de dire que le HTML généré faisait 74ko, ce qui est quand même pas rien ! (un masque de saisie avec une cinquantaine de champs/listes..., sur 10 onglets qui s'affichent et cachent)
Oui mais ca ca n'a rien a voir avec ton serveur.
* le temps de "fabrication" des polices de caractères. Si je prends un mozilla sans support xfs, c'est plus rapide !
Voire ci-dessus.
Paul GABORIT
À (at) Thu, 12 Feb 2004 14:17:09 +0100, paul écrivait (wrote):
Je ne comprends pas grand chose à FastCGI. Ni comment on l'installe, ni comment on l'utilise. de ce que j'ai compris, il faut une version spéciale de Perl (savvy ?), et reprendre tous les scripts. (source : http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch3perl.htm#3659 )
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm>
Il vous suffit de compiler mod_fastcgi pour Apache puis d'installer FCGI via CPAN. Et ça marche !
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Thu, 12 Feb 2004 14:17:09 +0100,
paul <paul.poulain_nospam@free.fr.invalid> écrivait (wrote):
Je ne comprends pas grand chose à FastCGI.
Ni comment on l'installe, ni comment on l'utilise.
de ce que j'ai compris, il faut une version spéciale de Perl (savvy ?), et
reprendre tous les scripts.
(source :
http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch3perl.htm#3659
)
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm>
Il vous suffit de compiler mod_fastcgi pour Apache puis d'installer FCGI via
CPAN. Et ça marche !
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Thu, 12 Feb 2004 14:17:09 +0100, paul écrivait (wrote):
Je ne comprends pas grand chose à FastCGI. Ni comment on l'installe, ni comment on l'utilise. de ce que j'ai compris, il faut une version spéciale de Perl (savvy ?), et reprendre tous les scripts. (source : http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch3perl.htm#3659 )
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm>
Il vous suffit de compiler mod_fastcgi pour Apache puis d'installer FCGI via CPAN. Et ça marche !
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
Emmanuel Florac
Dans article <c0fvqs$1u0n$, disait...
apache2 n'a pas l'air d'aimer : Cannot load /etc/httpd/2.0/modules/mod_speedycgi.so into server: /etc/httpd/2.0/modules/mod_speedycgi.so: undefined symbol: ap_suexec_enabled
Apache2 est une source d'emmerdes infinies. Son seul intérêt est de bien tourner sous Windows (autrement dit, aucun intérêt). Les 3/4 des modules et extensions Apache ne sont pas dispos pour Apache2 (exemple : essaie de faire tourner du SSL sur Apache2 qu'on rigole). Bref, un bon conseil : vire Apache2 et rétrograde sur la 1.3 vite fait.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <c0fvqs$1u0n$1@biggoron.nerim.net>,
paul.poulain_nospam@free.fr.invalid disait...
apache2 n'a pas l'air d'aimer :
Cannot load /etc/httpd/2.0/modules/mod_speedycgi.so into server:
/etc/httpd/2.0/modules/mod_speedycgi.so: undefined symbol:
ap_suexec_enabled
Apache2 est une source d'emmerdes infinies. Son seul intérêt est de bien
tourner sous Windows (autrement dit, aucun intérêt). Les 3/4 des modules
et extensions Apache ne sont pas dispos pour Apache2 (exemple : essaie de
faire tourner du SSL sur Apache2 qu'on rigole).
Bref, un bon conseil : vire Apache2 et rétrograde sur la 1.3 vite fait.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
apache2 n'a pas l'air d'aimer : Cannot load /etc/httpd/2.0/modules/mod_speedycgi.so into server: /etc/httpd/2.0/modules/mod_speedycgi.so: undefined symbol: ap_suexec_enabled
Apache2 est une source d'emmerdes infinies. Son seul intérêt est de bien tourner sous Windows (autrement dit, aucun intérêt). Les 3/4 des modules et extensions Apache ne sont pas dispos pour Apache2 (exemple : essaie de faire tourner du SSL sur Apache2 qu'on rigole). Bref, un bon conseil : vire Apache2 et rétrograde sur la 1.3 vite fait.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
paul
Paul GABORIT wrote:
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm> c'est un joke ? sous mozilla comme sous konqueror, la page est quasi vide,
et sans lien (sauf si j'ai mal vu...) -- Paul
Paul GABORIT wrote:
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm>
c'est un joke ? sous mozilla comme sous konqueror, la page est quasi vide,
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm> c'est un joke ? sous mozilla comme sous konqueror, la page est quasi vide,
et sans lien (sauf si j'ai mal vu...) -- Paul
Paul GABORIT
À (at) Mon, 16 Feb 2004 18:36:53 +0100, paul écrivait (wrote):
Paul GABORIT wrote:
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm> c'est un joke ? sous mozilla comme sous konqueror, la page est quasi vide,
et sans lien (sauf si j'ai mal vu...)
Ce n'est pas une blague. C'est la réalité. Je vous traduis le deuxième paragraphe:
« L'intégration de FCGI en Perl est disponible via le module Perl FCGI.pm. FCGI.pm ne nécessite plus la bibliothèque SFIO ou une version de Perl spécifique. Le module FCGI.pm est disponible via CPAN ou dans le répertoire 'perl' du kit. »
et vous aurez le module FCGI.pm installé et prêt à l'emploi.
Il ne vous reste plus qu'à installer mod_fcgi dans votre Apache et c'est utilisable.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 16 Feb 2004 18:36:53 +0100,
paul <paul.poulain_nospam@free.fr.invalid> écrivait (wrote):
Paul GABORIT wrote:
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm>
c'est un joke ? sous mozilla comme sous konqueror, la page est quasi vide,
et sans lien (sauf si j'ai mal vu...)
Ce n'est pas une blague. C'est la réalité. Je vous traduis le deuxième
paragraphe:
« L'intégration de FCGI en Perl est disponible via le module Perl
FCGI.pm. FCGI.pm ne nécessite plus la bibliothèque SFIO ou une version
de Perl spécifique. Le module FCGI.pm est disponible via CPAN ou dans
le répertoire 'perl' du kit. »
À (at) Mon, 16 Feb 2004 18:36:53 +0100, paul écrivait (wrote):
Paul GABORIT wrote:
Cette doc est vieillote... Lisez plutôt :
<http://www.fastcgi.com/devkit/doc/fcgi-perl.htm> c'est un joke ? sous mozilla comme sous konqueror, la page est quasi vide,
et sans lien (sauf si j'ai mal vu...)
Ce n'est pas une blague. C'est la réalité. Je vous traduis le deuxième paragraphe:
« L'intégration de FCGI en Perl est disponible via le module Perl FCGI.pm. FCGI.pm ne nécessite plus la bibliothèque SFIO ou une version de Perl spécifique. Le module FCGI.pm est disponible via CPAN ou dans le répertoire 'perl' du kit. »
