Re: [Koha-devel] Search speed
At 02:02 PM 2/2/2015 +0000, Tomas Cohen Arazi wrote:
Paul, while you are running your tests, could you please compare this both scenarios: - <use_zebra_facets>1</use_zebra_facets> - <use_zebra_facets>0</use_zebra_facets> Thanks PS: I have found that searchResults is too slow too.
I have posted notes, results and some NYTProf examples at <http://navalmarinearchive.com/z_koha/> -- the results are repeatable (I must have run NYTProf nearly 200 times.) Provisional conclusions are that <use_zebra_facets> = 1 (true) is not usable in production for a search that finds > 20k results. For smaller results, it might be acceptable, but is still appreciably slower than 3.08. Under the best circumstances (0-5 results) 3.08 responds in < 0.7 secs, 3.18 in 1.3 secs. At the other extreme (25k results), 3.08 requires 1.07 secs, 3.18 21+ secs. I have defined an "optimal" 3.18 combination (see green line, Graph 2) which runs at about half the speed of 3.08, but does not give 'Series', 'Places' and 'Titles' in the facets. One point that jumped out is that a best case 3.08 search executes 431207 statements and 76556 subroutine calls in 297 source files and 81 string evals whereas a worst case 3.18 executes 1238167 statements and 309905 subroutine calls in 591 source files and 132 string evals. (Even the worst case 308 appears much more efficient than the best case 3.18.) The use of -T to start Zebra is non-conclusive -- it vaguely slows down smaller result sets and vaguely speeds up larger result sets (testing is repeatable.) Robin was of course quite correct in his recent email, but I cannot explain even the minor variations experienced. I'm not at all certain how to file this as a bug, so will await any comments. Best -- Paul
For a fair comparison you should set facetNumRecs = 20 in zebradb/zebra-biblios-dom.xml. Because otherwise use_zebra_facets=0 is only processing the first 20 records, against 1000 from use_zebra_facets=1. Regarding the amount of statements/function calls, I don't think they mean too much. Some things got pulled from a +150 line piece of code into several helper functions. I don't think it introduces much overhead. REgards Tomas PS. if you play with facetNumRecs, remember to restart zebra each time you change it. On Wed, Feb 4, 2015 at 6:22 PM, Paul A <paul.a@navalmarinearchive.com> wrote:
At 02:02 PM 2/2/2015 +0000, Tomas Cohen Arazi wrote:
Paul, while you are running your tests, could you please compare this both scenarios: - <use_zebra_facets>1</use_zebra_facets> - <use_zebra_facets>0</use_zebra_facets> Thanks PS: I have found that searchResults is too slow too.
I have posted notes, results and some NYTProf examples at < http://navalmarinearchive.com/z_koha/> -- the results are repeatable (I must have run NYTProf nearly 200 times.)
Provisional conclusions are that <use_zebra_facets> = 1 (true) is not usable in production for a search that finds > 20k results. For smaller results, it might be acceptable, but is still appreciably slower than 3.08. Under the best circumstances (0-5 results) 3.08 responds in < 0.7 secs, 3.18 in 1.3 secs. At the other extreme (25k results), 3.08 requires 1.07 secs, 3.18 21+ secs.
I have defined an "optimal" 3.18 combination (see green line, Graph 2) which runs at about half the speed of 3.08, but does not give 'Series', 'Places' and 'Titles' in the facets.
One point that jumped out is that a best case 3.08 search executes 431207 statements and 76556 subroutine calls in 297 source files and 81 string evals whereas a worst case 3.18 executes 1238167 statements and 309905 subroutine calls in 591 source files and 132 string evals. (Even the worst case 308 appears much more efficient than the best case 3.18.)
The use of -T to start Zebra is non-conclusive -- it vaguely slows down smaller result sets and vaguely speeds up larger result sets (testing is repeatable.) Robin was of course quite correct in his recent email, but I cannot explain even the minor variations experienced.
I'm not at all certain how to file this as a bug, so will await any comments.
Best -- Paul
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
I have filled bug 13665 yesterday http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13665 2015-02-04 22:22 GMT+01:00 Paul A <paul.a@navalmarinearchive.com>:
At 02:02 PM 2/2/2015 +0000, Tomas Cohen Arazi wrote:
Paul, while you are running your tests, could you please compare this both scenarios: - <use_zebra_facets>1</use_zebra_facets> - <use_zebra_facets>0</use_zebra_facets> Thanks PS: I have found that searchResults is too slow too.
I have posted notes, results and some NYTProf examples at <http://navalmarinearchive.com/z_koha/> -- the results are repeatable (I must have run NYTProf nearly 200 times.)
Provisional conclusions are that <use_zebra_facets> = 1 (true) is not usable in production for a search that finds > 20k results. For smaller results, it might be acceptable, but is still appreciably slower than 3.08. Under the best circumstances (0-5 results) 3.08 responds in < 0.7 secs, 3.18 in 1.3 secs. At the other extreme (25k results), 3.08 requires 1.07 secs, 3.18 21+ secs.
I have defined an "optimal" 3.18 combination (see green line, Graph 2) which runs at about half the speed of 3.08, but does not give 'Series', 'Places' and 'Titles' in the facets.
One point that jumped out is that a best case 3.08 search executes 431207 statements and 76556 subroutine calls in 297 source files and 81 string evals whereas a worst case 3.18 executes 1238167 statements and 309905 subroutine calls in 591 source files and 132 string evals. (Even the worst case 308 appears much more efficient than the best case 3.18.)
The use of -T to start Zebra is non-conclusive -- it vaguely slows down smaller result sets and vaguely speeds up larger result sets (testing is repeatable.) Robin was of course quite correct in his recent email, but I cannot explain even the minor variations experienced.
I'm not at all certain how to file this as a bug, so will await any comments.
Best -- Paul
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (3)
-
Jonathan Druart -
Paul A -
Tomas Cohen Arazi