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é)
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é)
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é)
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é)
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é)
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é)
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Je vois les possibilités suivantes :
[...]
Je vois les possibilités suivantes :
[...]
Je vois les possibilités suivantes :
[...]
Le Thu, 12 Feb 2004 09:59:38 +0100, paul écrivait:
Et il y a peut être des outils simples à mettre en oeuvre pour tracer
certains éléments ?
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Le Thu, 12 Feb 2004 09:59:38 +0100, paul écrivait:
Et il y a peut être des outils simples à mettre en oeuvre pour tracer
certains éléments ?
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Le Thu, 12 Feb 2004 09:59:38 +0100, paul écrivait:
Et il y a peut être des outils simples à mettre en oeuvre pour tracer
certains éléments ?
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Bonjour,
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-)
Effectivement, mod_perl pourrait accelerer le processus.
* temps d'exécution du script (une imbrication de boucles qui ferait 100 000
fois un truc alors qu'on pourrait optimiser)
Ben ca c'est sur mais bon, si ya 150ko de scripts, va falloir fouiller !
* 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)
Oubli de creation d'indexes dans ta base sur des champs de requetes. Ca
* 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)
Essaye de juste telecharger le resultat a coups de wget, pour juger,
* c'est la mandrake 9.2 / Apache 2.0 qui sont mal compilés ou je sais pas
trop quoi d'autre.
Au mieux tu gagne 10% en recompilant.
Bonjour,
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-)
Effectivement, mod_perl pourrait accelerer le processus.
* temps d'exécution du script (une imbrication de boucles qui ferait 100 000
fois un truc alors qu'on pourrait optimiser)
Ben ca c'est sur mais bon, si ya 150ko de scripts, va falloir fouiller !
* 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)
Oubli de creation d'indexes dans ta base sur des champs de requetes. Ca
* 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)
Essaye de juste telecharger le resultat a coups de wget, pour juger,
* c'est la mandrake 9.2 / Apache 2.0 qui sont mal compilés ou je sais pas
trop quoi d'autre.
Au mieux tu gagne 10% en recompilant.
Bonjour,
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-)
Effectivement, mod_perl pourrait accelerer le processus.
* temps d'exécution du script (une imbrication de boucles qui ferait 100 000
fois un truc alors qu'on pourrait optimiser)
Ben ca c'est sur mais bon, si ya 150ko de scripts, va falloir fouiller !
* 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)
Oubli de creation d'indexes dans ta base sur des champs de requetes. Ca
* 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)
Essaye de juste telecharger le resultat a coups de wget, pour juger,
* c'est la mandrake 9.2 / Apache 2.0 qui sont mal compilés ou je sais pas
trop quoi d'autre.
Au mieux tu gagne 10% en recompilant.
Emmanuel Florac wrote:Le Thu, 12 Feb 2004 09:59:38 +0100, paul écrivait:Et il y a peut être des outils simples à mettre en oeuvre pour tracer
certains éléments ?
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Excellent le profiler. Hop, dans mes bookmarks...
Ca donne ca :
Exporter::export_ok_tags has -1 unstacked calls in outer
CGI::_set_attributes has 1 unstacked calls in outer
CGI::escapeHTML has 1 unstacked calls in outer
CGI::delete has 1 unstacked calls in outer
CGI::AUTOLOAD has -11 unstacked calls in outer
POSIX::load_imports has 1 unstacked calls in outer
POSIX::AUTOLOAD has -1 unstacked calls in outer
Exporter::Heavy::heavy_export has 27 unstacked calls in outer
CGI::register_parameter has 1 unstacked calls in outer
CGI::cookie has 1 unstacked calls in outer
CGI::previous_or_default has 1 unstacked calls in outer
Exporter::Heavy::heavy_export_ok_tags has 1 unstacked calls in outer
CGI::scrolling_list has 1 unstacked calls in outer
CGI::header has 1 unstacked calls in outer
Exporter::export has -27 unstacked calls in outer
CGI::_set_values_and_labels has 1 unstacked calls in outer
CGI::cache has 1 unstacked calls in outer
CGI::read_from_cmdline has 1 unstacked calls in outer
Total Elapsed Time = 2.278924 Seconds
User+System Time = 0.868924 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
16.1 0.140 0.160 4 0.0350 0.0399 C4::Date::BEGIN
14.3 0.125 0.206 1 0.1246 0.2059 main::build_tabs
8.06 0.070 0.398 7 0.0100 0.0569 C4::Auth::BEGIN
7.48 0.065 0.065 16860 0.0000 0.0000
C4::Koha::subfield_is_koha_interna
l_p
6.91 0.060 0.508 42 0.0014 0.0121 main::BEGIN
5.64 0.049 0.048 943 0.0001 0.0001 HTML::Template::param
4.60 0.040 0.200 5 0.0080 0.0399 C4::Reserves2::BEGIN
4.60 0.040 0.069 6 0.0066 0.0116 C4::Context::BEGIN
4.37 0.038 0.055 1 0.0377 0.0555 C4::Biblio::MARCgettagslib
3.45 0.030 0.030 1 0.0300 0.0298
C4::Interface::CGI::Output::output
_html_with_http_headers
3.45 0.030 0.050 6 0.0050 0.0083 C4::Output::BEGIN
2.30 0.020 0.020 11 0.0018 0.0018 CGI::_compile
2.30 0.020 0.020 5 0.0040 0.0040 C4::Biblio::BEGIN
2.30 0.020 0.020 65 0.0003 0.0003 Exporter::import
2.30 0.020 0.017 70 0.0003 0.0002 main::create_input
J'en conclus pas grand chose d'évident...
quelques questions cependant :
* le temps écoulé est nettement inférieur au temps user+system : cela
signifie t'il que c'est mySQL qui est le goulot d'étranglement?
(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).
Si oui, comment chercher plus précisémment?
* pourquoi C4::Date est il si "long" à s'exécuter ? C'est un bète truc qui
utilise Date::Manip et qui comporte 3 fonctions sans aucune boucle (juste
2-3 if)
* les "unstacked calls in outer" peuvent ils être à l'origine d'un
quelconque problème ?
Emmanuel Florac wrote:
Le Thu, 12 Feb 2004 09:59:38 +0100, paul écrivait:
Et il y a peut être des outils simples à mettre en oeuvre pour tracer
certains éléments ?
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Excellent le profiler. Hop, dans mes bookmarks...
Ca donne ca :
Exporter::export_ok_tags has -1 unstacked calls in outer
CGI::_set_attributes has 1 unstacked calls in outer
CGI::escapeHTML has 1 unstacked calls in outer
CGI::delete has 1 unstacked calls in outer
CGI::AUTOLOAD has -11 unstacked calls in outer
POSIX::load_imports has 1 unstacked calls in outer
POSIX::AUTOLOAD has -1 unstacked calls in outer
Exporter::Heavy::heavy_export has 27 unstacked calls in outer
CGI::register_parameter has 1 unstacked calls in outer
CGI::cookie has 1 unstacked calls in outer
CGI::previous_or_default has 1 unstacked calls in outer
Exporter::Heavy::heavy_export_ok_tags has 1 unstacked calls in outer
CGI::scrolling_list has 1 unstacked calls in outer
CGI::header has 1 unstacked calls in outer
Exporter::export has -27 unstacked calls in outer
CGI::_set_values_and_labels has 1 unstacked calls in outer
CGI::cache has 1 unstacked calls in outer
CGI::read_from_cmdline has 1 unstacked calls in outer
Total Elapsed Time = 2.278924 Seconds
User+System Time = 0.868924 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
16.1 0.140 0.160 4 0.0350 0.0399 C4::Date::BEGIN
14.3 0.125 0.206 1 0.1246 0.2059 main::build_tabs
8.06 0.070 0.398 7 0.0100 0.0569 C4::Auth::BEGIN
7.48 0.065 0.065 16860 0.0000 0.0000
C4::Koha::subfield_is_koha_interna
l_p
6.91 0.060 0.508 42 0.0014 0.0121 main::BEGIN
5.64 0.049 0.048 943 0.0001 0.0001 HTML::Template::param
4.60 0.040 0.200 5 0.0080 0.0399 C4::Reserves2::BEGIN
4.60 0.040 0.069 6 0.0066 0.0116 C4::Context::BEGIN
4.37 0.038 0.055 1 0.0377 0.0555 C4::Biblio::MARCgettagslib
3.45 0.030 0.030 1 0.0300 0.0298
C4::Interface::CGI::Output::output
_html_with_http_headers
3.45 0.030 0.050 6 0.0050 0.0083 C4::Output::BEGIN
2.30 0.020 0.020 11 0.0018 0.0018 CGI::_compile
2.30 0.020 0.020 5 0.0040 0.0040 C4::Biblio::BEGIN
2.30 0.020 0.020 65 0.0003 0.0003 Exporter::import
2.30 0.020 0.017 70 0.0003 0.0002 main::create_input
J'en conclus pas grand chose d'évident...
quelques questions cependant :
* le temps écoulé est nettement inférieur au temps user+system : cela
signifie t'il que c'est mySQL qui est le goulot d'étranglement?
(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).
Si oui, comment chercher plus précisémment?
* pourquoi C4::Date est il si "long" à s'exécuter ? C'est un bète truc qui
utilise Date::Manip et qui comporte 3 fonctions sans aucune boucle (juste
2-3 if)
* les "unstacked calls in outer" peuvent ils être à l'origine d'un
quelconque problème ?
Emmanuel Florac wrote:Le Thu, 12 Feb 2004 09:59:38 +0100, paul écrivait:Et il y a peut être des outils simples à mettre en oeuvre pour tracer
certains éléments ?
Il y a un module "profiler" pour perl, qui est normalement fait pour
découvrir les points de friction, justement.
Excellent le profiler. Hop, dans mes bookmarks...
Ca donne ca :
Exporter::export_ok_tags has -1 unstacked calls in outer
CGI::_set_attributes has 1 unstacked calls in outer
CGI::escapeHTML has 1 unstacked calls in outer
CGI::delete has 1 unstacked calls in outer
CGI::AUTOLOAD has -11 unstacked calls in outer
POSIX::load_imports has 1 unstacked calls in outer
POSIX::AUTOLOAD has -1 unstacked calls in outer
Exporter::Heavy::heavy_export has 27 unstacked calls in outer
CGI::register_parameter has 1 unstacked calls in outer
CGI::cookie has 1 unstacked calls in outer
CGI::previous_or_default has 1 unstacked calls in outer
Exporter::Heavy::heavy_export_ok_tags has 1 unstacked calls in outer
CGI::scrolling_list has 1 unstacked calls in outer
CGI::header has 1 unstacked calls in outer
Exporter::export has -27 unstacked calls in outer
CGI::_set_values_and_labels has 1 unstacked calls in outer
CGI::cache has 1 unstacked calls in outer
CGI::read_from_cmdline has 1 unstacked calls in outer
Total Elapsed Time = 2.278924 Seconds
User+System Time = 0.868924 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
16.1 0.140 0.160 4 0.0350 0.0399 C4::Date::BEGIN
14.3 0.125 0.206 1 0.1246 0.2059 main::build_tabs
8.06 0.070 0.398 7 0.0100 0.0569 C4::Auth::BEGIN
7.48 0.065 0.065 16860 0.0000 0.0000
C4::Koha::subfield_is_koha_interna
l_p
6.91 0.060 0.508 42 0.0014 0.0121 main::BEGIN
5.64 0.049 0.048 943 0.0001 0.0001 HTML::Template::param
4.60 0.040 0.200 5 0.0080 0.0399 C4::Reserves2::BEGIN
4.60 0.040 0.069 6 0.0066 0.0116 C4::Context::BEGIN
4.37 0.038 0.055 1 0.0377 0.0555 C4::Biblio::MARCgettagslib
3.45 0.030 0.030 1 0.0300 0.0298
C4::Interface::CGI::Output::output
_html_with_http_headers
3.45 0.030 0.050 6 0.0050 0.0083 C4::Output::BEGIN
2.30 0.020 0.020 11 0.0018 0.0018 CGI::_compile
2.30 0.020 0.020 5 0.0040 0.0040 C4::Biblio::BEGIN
2.30 0.020 0.020 65 0.0003 0.0003 Exporter::import
2.30 0.020 0.017 70 0.0003 0.0002 main::create_input
J'en conclus pas grand chose d'évident...
quelques questions cependant :
* le temps écoulé est nettement inférieur au temps user+system : cela
signifie t'il que c'est mySQL qui est le goulot d'étranglement?
(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).
Si oui, comment chercher plus précisémment?
* pourquoi C4::Date est il si "long" à s'exécuter ? C'est un bète truc qui
utilise Date::Manip et qui comporte 3 fonctions sans aucune boucle (juste
2-3 if)
* les "unstacked calls in outer" peuvent ils être à l'origine d'un
quelconque problème ?
FastCGI (qui est
plus simple à mettre en oeuvre que mod_perl).
Je ne comprends pas grand chose à FastCGI.
FastCGI (qui est
plus simple à mettre en oeuvre que mod_perl).
Je ne comprends pas grand chose à FastCGI.
FastCGI (qui est
plus simple à mettre en oeuvre que mod_perl).
Je ne comprends pas grand chose à FastCGI.
J'en conclus pas grand chose d'évident...
J'en conclus qu'une grande partie du temps d'execution consiste a
compiler ton script.
C'est bien possible...
Essaie de faire tourner ton script sous SpeedyCGI:
http://www.daemoninc.com/SpeedyCGI/
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
for (1..50) { main() }; # fais la meme chose 50 fois
# pour rendre les temps de compil negligeables
C'est une bonne idée :
quelques questions cependant :
* le temps écoulé est nettement inférieur au temps user+system : cela
signifie t'il que c'est mySQL qui est le goulot d'étranglement?
Essaie de diriger l'output de ton script vers >/dev/null, voire si c'est
pas ton xterm qui fait goulot d'etranglement.
(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 :
J'en conclus pas grand chose d'évident...
J'en conclus qu'une grande partie du temps d'execution consiste a
compiler ton script.
C'est bien possible...
Essaie de faire tourner ton script sous SpeedyCGI:
http://www.daemoninc.com/SpeedyCGI/
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
for (1..50) { main() }; # fais la meme chose 50 fois
# pour rendre les temps de compil negligeables
C'est une bonne idée :
quelques questions cependant :
* le temps écoulé est nettement inférieur au temps user+system : cela
signifie t'il que c'est mySQL qui est le goulot d'étranglement?
Essaie de diriger l'output de ton script vers >/dev/null, voire si c'est
pas ton xterm qui fait goulot d'etranglement.
(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 :
J'en conclus pas grand chose d'évident...
J'en conclus qu'une grande partie du temps d'execution consiste a
compiler ton script.
C'est bien possible...
Essaie de faire tourner ton script sous SpeedyCGI:
http://www.daemoninc.com/SpeedyCGI/
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
for (1..50) { main() }; # fais la meme chose 50 fois
# pour rendre les temps de compil negligeables
C'est une bonne idée :
quelques questions cependant :
* le temps écoulé est nettement inférieur au temps user+system : cela
signifie t'il que c'est mySQL qui est le goulot d'étranglement?
Essaie de diriger l'output de ton script vers >/dev/null, voire si c'est
pas ton xterm qui fait goulot d'etranglement.
(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 :
Essaye de juste telecharger le resultat a coups de wget, pour juger,
mais je pense reellement que c'est negligeable.
Essaye de juste telecharger le resultat a coups de wget, pour juger,
mais je pense reellement que c'est negligeable.
Essaye de juste telecharger le resultat a coups de wget, pour juger,
mais je pense reellement que c'est negligeable.