page size & speed display
Hello, I just did some tests on opac (a simple search), and save the html/css/js/... Here is my analysis : - opac-results = 16kB (3 results in my tests). OK, not too much - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could opac.css be "smallified" ? - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!! Some questions : - is cached in the browser ? (how to be sure / test that it is ?) - do we need all this javascript everytime & can't we avoid what is unneeded ? - isn't it slowing the page display ? on a DSL connection, one need between 3 and 4 seconds to see a result Which is slow imo (300KB/s line, firefox v2, server doing nothing else than answering me) comments/ideas welcomed ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
- opac-results = 16kB (3 results in my tests). OK, not too much - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could opac.css be "smallified" ? - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!!
Thank you for raising this question. JavaScript and CSS is cached. It's true, for sure. 16Kb or 100K, it's peanuts. But response time matter, I can't agree more. If you get a raw result page, so WITHOUT css and js: date; wget http://localhost/cgi-bin/koha/opac-search.pl?q=hugo; date You find that it takes 3-4 seconds, even localhost. So Koha has to be blamed. It takes this amount of time to Koha to interpret Perl scripts, do a search with Zebra, to request MySQL, to aggregate the result, to construct the HTML page with templating system. It would be interesting to see how better are performances with mod_perl. My feeling is that using mod_perl and session variables for syspref (avoiding to request syspref multiple times) would increase significantly performance. -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hello Frederic, Friday, June 27, 2008, 6:03:39 PM, you wrote:
- opac-results = 16kB (3 results in my tests). OK, not too much - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could opac.css be "smallified" ? - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!!
FD> Thank you for raising this question. JavaScript and CSS is cached. It's FD> true, for sure. 16Kb or 100K, it's peanuts. But response time matter, I FD> can't agree more. you can use mod_expires and mod_deflate for apache so for new clients the speed of loading page (firefox 2/3 or IE 6/7) will be no problem:) tested in our library:) bye -- <wojciech@zatorski.net> tel. +48 509-855-239; GG: 1500861; Skype: zatorski http://www.Zatorski.Net -- The especial genius of women I believe to be electrical in movement, intuitive in function, spiritual in tendency. -- Margaret Fuller (1810-1850) U.S. critic, social reformer, writer _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Frederic Demians <frederic@tamil.fr> wrote:
- opac-results = 16kB (3 results in my tests). OK, not too much - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could opac.css be "smallified" ? - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!!
Thank you for raising this question. JavaScript and CSS is cached. It's true, for sure. 16Kb or 100K, it's peanuts. But response time matter, I can't agree more.
No, the difference between 16Kb and 100Kb is not peanuts. 16Kb will display on nearly all mobile phones. 100Kb will not. I actually tested this this week. On my old SE k608i, I can load the Koha front page and do a search with a few results, but if there are the full 20ish results, the page is too big for the phone's browser. Now, that's not bad for something which hasn't had much attention, but we need to do better: more and more library borrowers have mobile phones, it lets them check the library before deciding to come in and there are never enough catalogue terminals at peak time anyway. I don't think we will do better before 3.0.0, but I think this is something to keep in mind and somewhere we could beat many ILSes. Slimming down the user interface could have all sorts of benefits. Chris has been doing some interesting performance testing recently http://blog.bigballofwax.co.nz/2008/06/22/testing-koha-with-memcached/ Hope that helps, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
No, the difference between 16Kb and 100Kb is not peanuts. 16Kb will display on nearly all mobile phones. 100Kb will not.
You're shifting to another subject. Improving Koha usability with mobile devices is interesting by itself but is not the question. Paul question is about relation between page size and server response time. He was inferring Koha slow response time from the size of the pages and static associated files. I replied that from this perspective difference between 16Kb and 100Kb is peanuts (ADSL connection). But you're right that for mobile phones peanuts size does matter. To improve response time, it's not necessary that Koha minimizes its result but rather run faster, via a caching system, or whatever. The URL you post make that clear and indicates what has to be done. -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hello MJ, Friday, June 27, 2008, 7:36:15 PM, you wrote: MR> Frederic Demians <frederic@tamil.fr> wrote:
- opac-results = 16kB (3 results in my tests). OK, not too much - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could opac.css be "smallified" ? - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!!
Thank you for raising this question. JavaScript and CSS is cached. It's true, for sure. 16Kb or 100K, it's peanuts. But response time matter, I can't agree more.
MR> No, the difference between 16Kb and 100Kb is not peanuts. 16Kb will MR> display on nearly all mobile phones. 100Kb will not. MR> I actually tested this this week. On my old SE k608i, I can load the MR> Koha front page and do a search with a few results, but if there are MR> the full 20ish results, the page is too big for the phone's browser. katalog.bg.szczecin.pl - search > euro 2Mbps connection: Firefox 3 - about ~3s - ~80KB Opera Mini (JAVA) - ~3s Opera Mobile 9.5 - ~3s GPRS connection: Opera Mini (JAVA) - ~5s Opera Mobile 9.5 - ~10s tested on my old glofiish M700.. bye -- <wojciech@zatorski.net> tel. +48 509-855-239; GG: 1500861; Skype: zatorski http://www.Zatorski.Net -- GENIUS: Some superior minds are unrecognized because there is no standard by which to weigh them. -- Joseph Joubert _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Witaj Wojciech,
GPRS connection: Opera Mini (JAVA) - ~5s Opera Mobile 9.5 - ~10s
not GPRS but EDGE connection...sorry.. bye -- The Main Library of Szczecin University. Computerization Department. http://bg.univ.szczecin.pl _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
(continuing investigations) I tried to investigate -d:DProf, but could not run a search with DProf. I modified the 1st line of opac-search.pl, to have #!/usr/bin/perl -d:DProf, but get the following error :
[Mon Jun 30 16:33:19 2008] [error] [client 127.0.0.1] Can't call method "config" on unblessed reference at /home/paul/koha.dev/head/C4/Context.pm line 616., referer: http://o15.bureau.paulpoulain.com/cgi-bin/koha/opac-main.pl
I also tried to do perl -d:DProf opac-main.pl, but get a nasty : Options must be name=>value pairs (odd number supplied) at /home/paul/koha.dev/head/C4/Context.pm line 234 any one with deeper Perl skill than me welcomed ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
(continuing investigations) I tried to investigate -d:DProf, but could not run a search with DProf.
opac-main.pl page profiling with Dprof give this result: Total Elapsed Time = 1.573963 Seconds User+System Time = 1.503963 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 15.2 0.229 0.348 24 0.0096 0.0145 XML::LibXML::_parse_sax_file 7.85 0.118 0.160 2496 0.0000 0.0001 XML::Simple::collapse 5.32 0.080 0.768 10 0.0080 0.0768 C4::Overdues::BEGIN 3.99 0.060 0.060 17 0.0035 0.0035 utf8::SWASHNEW 3.66 0.055 0.055 4776 0.0000 0.0000 XML::Simple::characters 3.32 0.050 0.069 7 0.0071 0.0099 XML::LibXML::SAX::BEGIN 3.32 0.050 0.099 15 0.0033 0.0066 C4::Context::BEGIN 2.66 0.040 1.191 11 0.0036 0.1083 C4::Auth::BEGIN 2.66 0.040 0.040 74 0.0005 0.0005 Exporter::export 2.59 0.039 0.039 556 0.0001 0.0001 DBI::st::execute 1.99 0.030 0.195 6 0.0050 0.0325 C4::Heading::BEGIN 1.99 0.030 0.529 9 0.0033 0.0588 C4::Reserves::BEGIN 1.99 0.030 1.350 9 0.0033 0.1500 main::BEGIN 1.99 0.030 0.059 197 0.0002 0.0003 Exporter::import 1.93 0.029 0.056 615 0.0000 0.0001 DBI::_new_sth Correct me if I'm wrong but I fear that a huge amount of time is burnt just reading Koha XML config file (do you see anything else?) Koha config file being an XML file is a good thing. It's not even a problem if reading XML file in Perl is slow (could be for MARC records). But this file shouldn't be read over and over. It should be an application-level information loaded only once at Koha application startup. Same applies for sysprefs, even if it seems not to have the same incidence on performances. So we come back to mod_perl which allow to define global (application/session) variables. -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Correct me if I'm wrong but I fear that a huge amount of time is burnt just reading Koha XML config file (do you see anything else?) Koha config file being an XML file is a good thing. It's not even a problem if reading XML file in Perl is slow (could be for MARC records). But this file shouldn't be read over and over. It should be an application-level information loaded only once at Koha application startup. Same applies for sysprefs, even if it seems not to have the same incidence on performances.
So we come back to mod_perl which allow to define global (application/session) variables.
Or memcached which allows us to cache the entire conf file as an object and access it that way. Ditto with the system preferences. Or indeed both memcached and mod_perl :) Chris _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Witaj Chris, W Twoim liście datowanym 30 czerwca 2008 (21:03:31) można przeczytać:
Or indeed both memcached and mod_perl :)
btw: using Koha without mod_perl is biiiig efficiency mistake.. ;) bye -- The Main Library of Szczecin University. Computerization Department. http://bg.univ.szczecin.pl _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Wojciech Zatorski a écrit :
Witaj Chris,
W Twoim liście datowanym 30 czerwca 2008 (21:03:31) można przeczytać:
Or indeed both memcached and mod_perl :) btw: using Koha without mod_perl is biiiig efficiency mistake.. ;)
does it mean you use Koha 3.0 with mod_perl currently ? and you don't have any problem with it ? That would be good to know... (not that you should have problems, but in koha 2.2, there were some, due to some Perl non clean programming) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hello Paul, Tuesday, July 1, 2008, 9:51:56 AM, you wrote: PP> does it mean you use Koha 3.0 with mod_perl currently ? and you don't PP> have any problem with it ? That would be good to know... nop.. i still using Koha 2.2.x with PerlResponseHandler ModPerl::RegistryPrefork, version 3.0 is still beta so .. not for my library.. PP> (not that you should have problems, but in koha 2.2, there were some, PP> due to some Perl non clean programming) yes i know.. so i changed a little Koha;) bye -- The Main Library of Szczecin University. Computerization Department. http://bg.univ.szczecin.pl _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Profiling an OPAC search with dprofpp -I gives this result: Total Elapsed Time = 4.046462 Seconds User+System Time = 3.676462 Seconds Inclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 38.6 0.008 1.420 1 0.0081 1.4195 C4::Search::searchResults 35.6 0.030 1.310 12 0.0025 0.1092 main::BEGIN 25.9 0.030 0.954 11 0.0027 0.0868 C4::Auth::BEGIN 24.1 0.889 0.889 240 0.0037 0.0037 utf8::SWASHNEW 23.8 0.010 0.875 11 0.0009 0.0796 C4::Members::BEGIN 23.0 - 0.847 1 - 0.8473 C4::Search::buildQuery 22.7 0.009 0.838 1 0.0094 0.8378 C4::Search::_remove_stopwords 22.5 0.258 0.830 40 0.0065 0.0207 C4::Biblio::get_biblio_authorised_ values 21.5 0.100 0.792 10 0.0100 0.0792 C4::Overdues::BEGIN 19.0 0.010 0.700 63 0.0002 0.0111 XML::LibXML::SAX::_parse 19.0 - 0.699 63 - 0.0111 XML::SAX::Base::parse 17.8 0.010 0.657 18 0.0006 0.0365 C4::Circulation::BEGIN 16.7 - 0.616 23 - 0.0268 XML::Simple::XMLin 16.7 - 0.616 23 - 0.0268 C4::Context::read_config_file 16.7 - 0.616 23 - 0.0268 C4::Context::new So obviously, there's room for improvement: * utf8::SWASHNEW ??? * _remove_stopword consume 22.7% of time * XML::LibXML::SAX::_parse take 19% of time just to parse conf file Otherwise, using XSLT for displaying biblio records won't help performances if XSL transformer is not pre-parsed and cached in memory. -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Frederic Demians <frederic@tamil.fr> wrote:
Profiling an OPAC search with dprofpp -I gives this result:
Total Elapsed Time = 4.046462 Seconds User+System Time = 3.676462 Seconds Inclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 38.6 0.008 1.420 1 0.0081 1.4195 C4::Search::searchResults 35.6 0.030 1.310 12 0.0025 0.1092 main::BEGIN 25.9 0.030 0.954 11 0.0027 0.0868 C4::Auth::BEGIN 24.1 0.889 0.889 240 0.0037 0.0037 utf8::SWASHNEW 23.8 0.010 0.875 11 0.0009 0.0796 C4::Members::BEGIN 23.0 - 0.847 1 - 0.8473 C4::Search::buildQuery 22.7 0.009 0.838 1 0.0094 0.8378 C4::Search::_remove_stopwords 22.5 0.258 0.830 40 0.0065 0.0207 C4::Biblio::get_biblio_authorised_ values 21.5 0.100 0.792 10 0.0100 0.0792 C4::Overdues::BEGIN 19.0 0.010 0.700 63 0.0002 0.0111 XML::LibXML::SAX::_parse 19.0 - 0.699 63 - 0.0111 XML::SAX::Base::parse 17.8 0.010 0.657 18 0.0006 0.0365 C4::Circulation::BEGIN 16.7 - 0.616 23 - 0.0268 XML::Simple::XMLin 16.7 - 0.616 23 - 0.0268 C4::Context::read_config_file 16.7 - 0.616 23 - 0.0268 C4::Context::new
These %s add up to considerably more than 100% don't they? What does that mean? Also, 23 calls to C4::Context::read_config_file? Are we failing to detect that we've loaded it, or is that a misinterpretation? Finally, CumulS(XML::LibXML::SAX::_parse) > CumulS(C4::Context::read_config_file) which reminds me that koha-conf.xml isn't the only XML file in Koha - are others used here? Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
These %s add up to considerably more than 100% don't they? What does that mean?
This is a dprofpp -I result. It means that it displays subroutine times inclusive of child subroutine times. I suppose for example that C4::Context::new call C4::Context::read_config_file that call XML::Simple::XMLin. So we know that globally 16.7% of response time is spent reading config file. If, thanks to mod_perl, a
Also, 23 calls to C4::Context::read_config_file? Are we failing to detect that we've loaded it, or is that a misinterpretation?
So reading config file may be not so slow but it is called 23 times! If you add a warning in this procedure, you see it is called from those modules: 1. Context.pm 2. Output.pm 3. Languages.pm 4. Auth.pm 5. Members.pm 6. Dates.pm 7. Log.pm 8. Circulation.pm 9. Stats.pm 10. Reserves.pm 11. Biblio.pm 12. Koha.pm 13. Branch.pm 14. ClassSource.pm 15. ClassSortRoutine.pm 16. Heading.pm 17. Search.pm 18. XSLT.pm 19. Items.pm 20. Accounts.pm 21. Overdues.pm 22. VirtualShelves.pm 23. Tags.pm 23 calls! It has to be fixed.
Finally, CumulS(XML::LibXML::SAX::_parse) > CumulS(C4::Context::read_config_file) which reminds me that koha-conf.xml isn't the only XML file in Koha - are others used here?
marcxml biblio records? Even on a setup without XSLT? _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Frederic Demians <frederic@tamil.fr> wrote:
So reading config file may be not so slow but it is called 23 times! If you add a warning in this procedure, you see it is called from those modules: [...]
Why isn't it as simple as caching the result, as in diff --git a/C4/Context.pm b/C4/Context.pm index 3cba0ff..1cdca9b 100644 --- a/C4/Context.pm +++ b/C4/Context.pm @@ -17,7 +17,7 @@ package C4::Context; # Suite 330, Boston, MA 02111-1307 USA use strict; -use vars qw($VERSION $AUTOLOAD $context @context_stack); +use vars qw($VERSION $AUTOLOAD $context @context_stack %config); BEGIN { if ($ENV{'HTTP_USER_AGENT'}) { @@ -227,8 +227,11 @@ Returns undef in case of error. =cut sub read_config_file { # Pass argument naming config file to read - my $koha = XMLin(shift, keyattr => ['id'], forcearray => ['listen', 'server', 'serverinfo']); - return $koha; # Return value: ref-to-hash holding the configuration + my $filename = shift; + if ( !defined($config{$filename}) ) { + $config{$filename} = XMLin(shift, keyattr => ['id'], forcearray => ['listen', 'server', 'serverinfo']); + } + return $config{$filename}; # Return value: ref-to-hash holding the configuration } # db_scheme2dbi ? I guess we could do a bit better by caching and cloning the C4::Context $self hashref but that seems a bit trickier to me.
Finally, CumulS(XML::LibXML::SAX::_parse) > CumulS(C4::Context::read_config_file) which reminds me that koha-conf.xml isn't the only XML file in Koha - are others used here?
marcxml biblio records? Even on a setup without XSLT?
I think so. I don't recall setting up XSLT explicitly, but I've certainly had errors about invalid marcxml spat at me. Thanks for investigating this, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi, On Tue, Jul 1, 2008 at 9:06 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Frederic Demians <frederic@tamil.fr> wrote:
So reading config file may be not so slow but it is called 23 times! If you add a warning in this procedure, you see it is called from those modules: [...]
Why isn't it as simple as caching the result, as in
I think it probably really is that simple, at least for now - could you test your approach and submit?
marcxml biblio records? Even on a setup without XSLT?
I think so. I don't recall setting up XSLT explicitly, but I've certainly had errors about invalid marcxml spat at me.
Right; because all MARC records are processed through MARC::File::XML at various points, there will be XML parsing going on even if the XSLT display options are not being used. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi 2008/7/1 Galen Charlton <galen.charlton@liblime.com>:
Hi,
I think so. I don't recall setting up XSLT explicitly, but I've certainly had errors about invalid marcxml spat at me.
Right; because all MARC records are processed through MARC::File::XML at various points, there will be XML parsing going on even if the XSLT display options are not being used.
Yes, Indeed, As far as I know, MARC::File::XML uses XML::LibXML to parse marcxml and create MARC::Record and we rely on MARC::File::XML since we decided that XML records were the authoritative ones. So would it be for simple result display, we silently use XML::LibXML my 2 cts -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Why isn't it as simple as caching the result, as in
I think it probably really is that simple, at least for now - could you test your approach and submit?
Yes, but context objects will be created 23 times, one per module using C4::Context. I just send a patch which uses class variable for default context. -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
On Wed, Jul 2, 2008 at 2:31 AM, Frederic Demians <frederic@tamil.fr> wrote:
Yes, but context objects will be created 23 times, one per module using C4::Context. I just send a patch which uses class variable for default context.
Good eye, Frédéric. Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Yes, but context objects will be created 23 times, one per module using C4::Context. I just send a patch which uses class variable for default context. Good eye, Frédéric.
A tribute must be paid to MJ Ray who expressed his astonishment about C4::Context::read_config_file being called 23 times... -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
On Tue, Jul 01, 2008 at 09:51:56AM +0200, Paul POULAIN wrote:
Wojciech Zatorski a écrit :
btw: using Koha without mod_perl is biiiig efficiency mistake.. ;)
does it mean you use Koha 3.0 with mod_perl currently ? and you don't have any problem with it ? That would be good to know... (not that you should have problems, but in koha 2.2, there were some, due to some Perl non clean programming)
I would lean towards making Koha FastCGI compatible, rather than mod_perl compatible. FastCGI is a much more flexible solution (can still be run as normal CGI, or with many webservers as FastCGI), and from what I have heard, ends up using less memory and CPU than mod_perl. -kolibrie _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Frederic - Thanks for your work on profiling the code. I haven't tried it myself, but I've heard great things about the NY Times Profiler. http://open.blogs.nytimes.com/2008/03/05/the-new-york-times-perl-profiler/ http://search.cpan.org/dist/Devel-NYTProf/ thought it might be a useful tool if anyone is getting more interested in investigating this stuff. -Andy _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
participants (9)
-
Andrew Moore -
Chris Cormack -
Frederic Demians -
Galen Charlton -
Henri-Damien LAURENT -
MJ Ray -
Nathan Gray -
Paul POULAIN -
Wojciech Zatorski