Hie, You have to consider it with the number of users connected at the same time. For earch user connected : MySQL server will require some CPU, a lot of RAM and some hard disk performance. Apache will need good CPU performance (to execute Perl). So it depends on your hardware. If you have simple dual-core systems with feew RAM, you should use a dedicated server for MySQL. It will be performant to serve many users, but with some waiting time. If you have a big multi-core system with lot of RAM, you can use one server. In this case, you may use a dedicated hard disk for MySQL, to have a good read/write performance. In addition, I think CPU frequency is important to have a fast compilation+execution of Perl script. In conclusion, I'd say that the problem should be cured at its source. I mean that the number of SQL queries and cache systems should be optimized in Koha code. I think that database should always be on a dedicated server, it is nearly an OS itself and needs all hardware resources. PS : have a look at PCI Express 10Gb/s Ethernet cards. Best regards, On Fri, Apr 6, 2012 at 12:53 AM, Dobrica Pavlinusic <dpavlin@rot13.org>wrote:

On Thu, Apr 05, 2012 at 02:03:02PM +0200, jonathan DUPERRIER wrote:

...

Hello,

I would like to know if the installation of Koha with a MySQL database on another server than the application may affect the performance of Koha. The MySQL server and application are on the same LAN, regardless of any order might be slowdown during query execution.

It seems it does.

I did some measurements with DBD::Gofer which is network serialisation layer which can introduce local cache with:

DBI_AUTOPROXY=dbi:Gofer:transport=null;cache=1

This pass SQL query to original database, but cache queries in memory, just like MySQL query cache does.

This has performance impact on generated search page:

2.952961 s page load time and 0.713 s of DBI time to 3.709371 s page load time and 1.634 s of DBI time

This are plack numbers, but are useful for estimating performance implact of Gofer itself. It roughly doubles number of perl statements execuited in NYTProf.

And now numbers from caching layer: we issue 1674 queries of which 927 are unique. That means we are generating double traffic to database so using local caching via DBD::Gofer (which is part of standard DBI install, BTW) might buy you some performance.

There are some low-hanging fruit to pick here, I think :-)

-- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin _______________________________________________ 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/

-- Fridolyn SOMERS fridolyn.somers@gmail.com Marsillargues - France <fridolyn.somers@gmail.com>

Am 06.04.12 09:58, schrieb Paul Poulain:

Le 06/04/2012 09:43, Fridolyn SOMERS a écrit :

...

In conclusion, I'd say that the problem should be cured at its source. I mean that the number of SQL queries and cache systems should be optimized in Koha code. +1000 = the problem shoud be cured at its source, and that's the goal of the thread "RFC: Koha::Persistent - for plack and general performance" that dobrika started and my counter proposal. This thread should have many contributions, and, for now, it has none :(

FWIW, once I am done with removing MySQLisms it is my plan to refactor at least some the SQL queries. I am sure quite some substantial performance gain can be achieved in some areas.