[Koha] MySQL database server, dedicated vs virtual

[Jonathan Druart]

Paul,

Hum sounds like I already answered you the same things a few months ago...

Well, you are still comparing 3.8 with 3.18, last release is 16.11, with
plack and memcached support.
What you missed (living in the past):
Bug 15342 - Performance 3.22 - Omnibus
Bug 7172 - Omnibus for Plack variable scoping problems
Bug 11998 - Syspref caching issues (and all other cache improvements)
And all related.

I will not list all the security issues we fixed during the last 4 years...

For the respect of all the developers and testers working on Koha, I would
appreciate if you could repeat your benchmarks with the stable and
maintained releases (ie. with plack and memcached).
If you find performance issues, I will be happy to find the bottlenecks and
improve them.

But please stop repeating endlessly that 3.18 is slower than 3.8. It does
not bring anything to the discussion.

On a side note, we lack testers. Patches are in the queue to support new
versions of MySQL (out of the box, because you can still use MariaDB or
tweak the MySQL config to make it works).


On Mon, 5 Dec 2016 at 16:33 Paul A <paul.a at navalmarinearchive.com> wrote:

> At 02:02 PM 12/4/2016 +0000, Marcel de Rooy wrote:
> >Please note:
> >Staying at Koha 3.8 is not recommended. The current release (16.11 ==
> >3.26) is already 9(!) release cycles behind..
> >And I would not advise others to do so.
>
> Marcel -- I don't know how you could read my comments as a "recommendation"
> or "advice" to stay with Koha 3.8.24. I mentioned, in response to RG's post
> "... was about 60-80% slower... ", that we had done some lengthy analysis
> of search speed (which I carried out with the assistance of the the Koha
> community and openly made available) and made the disappointing decision to
> remain with that version, under our specific circumstances. And I concluded
> with "YMMV" which stands for "your mileage might vary."
>
> Perhaps I should have been clearer: Koha was our indisputable choice for an
> OPAC (3.4.x) back in 2011; we are not a lending library, so the undoubted
> enhancements for lending libraries are irrelevant to our needs; the
> corollary is that if such enhancements have negative effects on our
> requirements, we very definitely look at them (sandbox level) but will not
> use them in production (i.e. on the public web interface.)
>
> Our production servers are all Ubuntu LTS based: this is a two to five year
> cycle; we do not have the budget or necessary volunteer hours to review
> monthly or bi-monthly changes (except security concerns); our overriding
> concern is total, hands-off stability; I have no idea if we are the only
> Koha-based library that uses a similar LTS approach.
>
> Koha 3.8.24 was released 5/29/2014, corresponding to the Ubuntu 14 LTS
> cycle. We recently upgraded two of our production servers to Ubuntu 16 LTS
> for other databases, but unless I am mistaken Koha 16.11 does not install
> (or at least not easily in our experience, and we have tried) on that o/s.
> So we maintained an additional, dedicated 14 server (with three years
> remaining Ubuntu support to 2019) for the OPAC when we followed the Ubuntu
> cycle. Again, this was disappointing, and again this represents only our
> very specific needs.
>
> So, when I say "your mileage might vary" I mean exactly that -- we probably
> are atypical of many Koha users, but are extremely happy and proud of our
> Koha OPAC -- so, if it wasn't clear, let me state that our analysis of
> search speed is *not* any sort of recommendation.
>
> Best regards -- Paul
>
>
>
> >Marcel
> >
> >
> >________________________________
> >Van: Koha <koha-bounces at lists.katipo.co.nz> namens Paul A
> ><paul.a at navalmarinearchive.com>
> >Verzonden: vrijdag 2 december 2016 21:53
> >Aan: koha
> >Onderwerp: Re: [Koha] MySQL database server, dedicated vs virtual
> >
> >Roger,
> >
> >We also looked into the "search performance" last year. We are not a
> >lending library, so cataloguing and OPAC are our primary concerns. Please
> >see <http://navalmarinearchive.com/z_koha/> for the detailed tech
> analysis
> >and conclusions.
> >
> >You mention below that "Koha does not benefit a lot from multiple CPU
> cores
> >since each CGI request is typically processed by one CPU except for the
> >Zebra searches and database queries which run as separate processes."
> >
> >I talked to Intel about CPU core cross-threading as it was a very obvious,
> >high-load, show-stopper with Zebra. The Zebra author never replied to my
> >queries. Intel were not optimistic, as kernel (and software) were not
> their
> >bailliwick. I do not know if Plack or Elastic have worked around this.
> >
> >These are hardware (perhaps software usage of core capability), not Koha,
> >restrictions. Tweaking memcached can have appreciable benefits. But the
> >bottom line remains that if a single CPU core hits 101-104%, search
> >functions descend into the "swimming upstream in treacle" world.
> >
> >We made the very conscious (but disappointing) decision to stay with Koha
> >3.8.24 based on our test results. I do spend quite some time testing later
> >versions at "sandbox" level, but have not been able to reproduce "older"
> >search speed.
> >
> >YMMV -- Paul
> >Production: Koha 3.8.24 on 14.04.2 LTS (GNU/Linux 3.13.0-43-generic
> >x86_64), 8-core I7 processors, 64 Gigs RAM, all SSD drives.
>