I use plack with the koha.psgi file from the source (misc/plack/koha.psgi) and the Proxy/ProxyPass directives in the apache config. For more info on what does the tests, please see the first lines on the wiki page, which point to bug 13690 comment 2: === I have created a selenium script (see bug 13691) which: - goes on the mainpage and processes a log in (main) - creates a patron category (add patron category) - creates a patron (add patron) - adds 3 items (add items) - checks the 3 items out to the patron (checkout) - checks the 3 items in (checkin) === 2015-11-09 20:19 GMT+00:00 Tomas Cohen Arazi <tomascohen@gmail.com>:

2015-11-09 13:30 GMT-03:00 Jonathan Druart <jonathan.druart@bugs.koha-community.org>:

...

Hi devs,

Please have a look at the these benchmarks:

http://wiki.koha-community.org/wiki/Benchmark_for_3.22

It is expected that broader DBIC usage would have more footprint [1]. I wonder what your Plack setup is, as the packages integration uses Starman with prefork, so the load time should not be user-noticeable.

Hum...

I agree with Paul A, that running in Plack feels so close to zero-time, that those numbers sound unrealistic. Maybe we should go back to caching sysprefs (you could test that if you have the VM ready for it) and have the workers last shorter time (something between 1 and 5 requests) [2].

[1] Only as an example, we are now retireving sysprefs through DBIC. [2] Dobrica mentioned this in Marseille. I don't recall how many beers we had before that.

-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F

Mirko Tietgen schrieb am 27.11.2015

I have not tried the old benchmark script (or tried Jonathan's test) yet, but so far I share Jonathan's findings.

I added the benchmark results to the wiki page at http://wiki.koha-community.org/wiki/Benchmark_for_3.22#Koha_3.8_on_Raspberry... Cheers, Mirko

At 11:56 AM 11/28/2015 +0100, Mirko Tietgen wrote:

NYTProfile for searches in the OPAC and in the staff client, run on the RPi2 with Koha 3.22

For /usr/share/koha/opac/cgi-bin/opac/opac-search.pl: http://abunchofthings.net/koha/profile/opacsearch/

For /usr/share/koha/intranet/cgi-bin/catalogue/search.pl: http://abunchofthings.net/koha/profile/staffsearch/

Mirko, Your numbers appear close to the testing we did (compare OPAC search 3.08.05 and 3.18.3) in January this year (see <http://navalmarinearchive.com/z_koha/>) -- you obviously use 3.22 and a different database (how many biblios? and how many results found? I tested, by varying the search string, for anywhere between 0 and 25540 "results found" in a db with ~26k biblios and 50k items -- details on our website as above.) I could try and assist with 3.08 on a fast server (*not* a Raspberry Pi ;={ ) if there's any advantage to you (I'd try it on a production back-up server, hopefully minimum disruption, but would probably need your scripts and db.) While I no longer have NYTProf installed, I could do any "lesser" testing, or maybe even reinstall it... But then again, maybe the numbers I posted are sufficient for your comparisons? As you so diplomatically suggest in your first email on this subject, the search speed was the deciding factor that keeps us on 3.08 (now release 24) -- we just couldn't envision twenty second searches in production. Best regards -- Paul

At 10:16 AM 11/29/2015 +0100, Mirko Tietgen wrote:

Hi Paul, I only used figures for 3.8 because I already had them. I am not particularly interested in that version, as it is very out of date and has not had a maintenance release in almost two years. You should consider upgrading.

Hi Mirko, Many thanks for the reply. We update our production servers every two years, so in Jan. of 2015 compared our existing 3.8.05 with the "latest" 3.18.3. The bottom line was that 3.8 could completely render "normal" searches (say less than 200 results) in < 750 ms (new faster server < 550ms) while 3.18 had trouble beating 2000ms, and "fell off the edge of the world" at 20+ seconds for the (abnormal?) cases of > 19,000 results. [1] The staff interface for searching authorities (and pulling them up to edit them) took a slightly worse hit. I look forward to your trials with Plack, but *if* I understand Plack correctly, it will improve the web rendering only -- not the Koha/perl/Zebra/MySQL component of searching which is where 3.18 took a bad hit for identical searches : 3.08: 604881 statements and 124374 subroutine calls in 306 source files and 84 string evals. 3.18: 1005756 statements and 247583 subroutine calls in 590 source files and 132 string evals. I can't explain this, but maybe you can? Your benchmarking for 3.22 (OK, different db) shows: 3.22: 1809166 statements and 578656 subroutine calls in 657 source files and 142 string evals. so this progression through the versions, for "just plain searching" has doubled the subroutine calls and source files (3.22 probably more than that.) Is this mission creep? or security? or even necessary? I certainly don't want to be negative about all the tremendous work that goes into Koha, but have to wonder why "core functions" have apparently been negatively impacted by added utilities, more modern web experience and all the other highly desirable goodies. Best -- Paul [1] due partly to Zebra swamping a single core of the Intel I7 CPU (we tried the "-T" option, but "multi-threading" still went to a single core.)

3.16 has been maintained until recently and would have been an option when you did your tests in January.

I am doing the benchmarks with 3.16 and Plack atm.

-- Mirko

_______________________________________________ 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/

--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

Tomas Cohen Arazi schrieb am 27.11.2015

Could you try reverting to old DBI syspref retrieval in C4::Context?

I did a lot of speed tests over the weekend, and I think that is not the main problem. I do not see a huge drop in speed in all areas, but search speed with Plack in 3.18 is 1/3 of that in 3.16. I found two areas so far that seem problematic. 1. The anti-cache stuff introduced in bug 11842 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11842 The cache is deleted all the time, eg. the framework structure is fetched again and again for every single result in a search (related to 2. below) When I revert that patch, I speed up search from 30 to 23 seconds for a repeated search in OPAC with multiple results (once the frameworks are cached). Not enough, but a good start. 2. The handling of XSLT when building the results page, related to C4::XSLT. When I tested Koha 3.8 on the Raspberry Pi in 2012, a search with one result took 2x the time of one with multiple results, because after finding the single result, you get redirected to the detail page automatically. Nowadays, the search with a single result is much faster than that of one with multiple results, because we lose a lot of time building the results page. Also, a search with multiple results is twice as fast when XSLT view is disabled in the sysprefs. I have not tried how it was in 3.16 yet. For every single result in a search, a lot of things are repeated all over again. A huge bunch of sysprefs is fetched every time, even though it is not likely they will change while fetching all results of one search query. GetMarcStructure seems to be a problem (see 1. above) but others may be too. Bug 11051 seems related. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11051 There is probably more and I will do more testing. Jonathan: could you check if the first point may be relevant for your selenium tests? Cheers, Mirko

After some quick tests: on 3.22, using the selenium tests (see bug 13691 and the wiki page "Benchmark for 3.22"): I have tried without plack only: 3.22 + memcached, 3.22 - memcached with and without 11842 And I have not noticed a difference (same execution time for the whole bench of tests). 2015-11-30 10:07 GMT+00:00 Mirko Tietgen <mirko@abunchofthings.net>:

Tomas Cohen Arazi schrieb am 27.11.2015

...

Could you try reverting to old DBI syspref retrieval in C4::Context?

I did a lot of speed tests over the weekend, and I think that is not the main problem.

I do not see a huge drop in speed in all areas, but search speed with Plack in 3.18 is 1/3 of that in 3.16.

I found two areas so far that seem problematic.

1. The anti-cache stuff introduced in bug 11842 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11842

The cache is deleted all the time, eg. the framework structure is fetched again and again for every single result in a search (related to 2. below)

When I revert that patch, I speed up search from 30 to 23 seconds for a repeated search in OPAC with multiple results (once the frameworks are cached). Not enough, but a good start.

2. The handling of XSLT when building the results page, related to C4::XSLT.

When I tested Koha 3.8 on the Raspberry Pi in 2012, a search with one result took 2x the time of one with multiple results, because after finding the single result, you get redirected to the detail page automatically.

Nowadays, the search with a single result is much faster than that of one with multiple results, because we lose a lot of time building the results page.

Also, a search with multiple results is twice as fast when XSLT view is disabled in the sysprefs. I have not tried how it was in 3.16 yet.

For every single result in a search, a lot of things are repeated all over again. A huge bunch of sysprefs is fetched every time, even though it is not likely they will change while fetching all results of one search query. GetMarcStructure seems to be a problem (see 1. above) but others may be too. Bug 11051 seems related. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11051

There is probably more and I will do more testing.

Jonathan: could you check if the first point may be relevant for your selenium tests?

Cheers,

Mirko

_______________________________________________ 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/