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 <[email protected]> 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 > [email protected] > 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
_______________________________________________ Koha-devel mailing list [email protected] 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/
