Re: [Koha-devel] Performance of Koha and usage of remote MySQL server

2012-04-06 Thread Fridolyn SOMERS
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 simpl

Re: [Koha-devel] Solr / zebra / search in Koha 3.10 => starting a workgroup

2012-04-06 Thread Fridolyn SOMERS
I agree, CCL for all search engines. Some PQF queries exiting in Koha (in authorities search for example) can easily be converted in CCL. On Thu, Apr 5, 2012 at 5:52 PM, Zeno Tajoli wrote: > Hi to all, > > Il 30/03/2012 18:15, Paul Poulain ha scritto: > > > > As you know, our main goal for the

Re: [Koha-devel] Performance of Koha and usage of remote MySQL server

2012-04-06 Thread 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

Re: [Koha-devel] Performance of Koha and usage of remote MySQL server

2012-04-06 Thread Marc Balmer
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

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Chris Cormack
On 5 April 2012 23:20, Paul Poulain wrote: > Le 04/04/2012 17:48, Dobrica Pavlinusic a écrit : >> I would like to propose new module which would keep track of all >> persistant values for rest of Koha code. > Hi Dobrika, > >> As opposed to C4::Cache* which never got implemented in all code, >> I p

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Chris Cormack
Apologies, Dobrica, not Dobrika. :) ___ 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 : ht

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Frédéric Demians
Since Koha is a multi-threading app, with or without Plack, caching is not that easy. There is already some caching but at thread level. Memcached can be a solution for sharing cached data structure (like framework for example) between threads, and even between threads running on multiple servers.

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Paul Poulain
Le 06/04/2012 10:14, Chris Cormack a écrit : >> The memcached is a workaround according to me: it put the result in a >> memcached server, so doesn't care of the fact that the CGI dies, but the >> price of reaching the page is very high, limiting the gain (chris_c said >> many times that memcached

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Ian Walls
Would it be practical and efficient to cache shared data to file (or a series of files)? My understanding is that reading files is faster than doing SQL queries, but not as fast as accessing memcached. But, the file would have the advantage of being non-threaded. I don't think configuration thin

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Paul Poulain
Le 06/04/2012 12:08, Frédéric Demians a écrit : > Dobrica Koha::Persistant module make sense to me. It has thread > in-memory caching now, but can be extended to implement multi-thread > in-memory or in memcached (or redis, MySQL...) caching. The question is > more: is it necessary to mix caching

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Chris Cormack
> > As you're experimented in caching, a question: I think cache > invalidation can be made by 2 different techniques: > * when a data make the cache invalid, it send a message to all cache to > say "hey, cache is reseted". Cache is reseted, and next time a data is > requested it won't be in the ca

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Chris Cormack
2012/4/6 Ian Walls : > Would it be practical and efficient to cache shared data to file (or a > series of files)?  My understanding is that reading files is faster than > doing SQL queries, but not as fast as accessing memcached.  But, the file > would have the advantage of being non-threaded.  I d

Re: [Koha-devel] Solr / zebra / search in Koha 3.10 => starting a workgroup

2012-04-06 Thread Jared Camins-Esakov
I disagree. As it stands now, CCL is not an acceptable alternative to PQF. CCL can be ambiguous, and runs into all sorts of problems with quoting, etc. The only way I can see a CCL-style query language being a viable option for all searching would be if Koha had a new search parser that was well-de

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Paul Poulain
Le 06/04/2012 12:40, Chris Cormack a écrit : >> Am I right if I say that the 1st technique is the best and is what is >> achieved by ->flush_cache() method of (memoize::)memcached ? > > The third option, and best option imho is when a value is change, it > is injected into the cache at that point.

Re: [Koha-devel] Solr / zebra / search in Koha 3.10 => starting a workgroup

2012-04-06 Thread Zeno Tajoli
Hi, Il 06/04/2012 13:27, Jared Camins-Esakov ha scritto: > I disagree. As it stands now, CCL is not an acceptable alternative to PQF. > CCL can be ambiguous, and runs into all sorts of problems with quoting, > etc. Probaly not a pure CCL but something very similar to the present opac queries tha

Re: [Koha-devel] Solr / zebra / search in Koha 3.10 => starting a workgroup

2012-04-06 Thread Jared Camins-Esakov
Zeno, > Probaly not a pure CCL but something very similar to the present opac > queries that are so: > > idx=ti,phr > &q=red+winter > &op=and > > &idx=au,wrdl > &q=white > &op=and > > &idx=kw > &op=and > > &idx=kw > > &sort_by=call_number_asc&do=Search > If we're using that we could just as easi

Re: [Koha-devel] RFC: Koha::Persistent - for plack and general performance

2012-04-06 Thread Dobrica Pavlinusic
I will try to include answers to all questions which where addressed to me in thread in this single message. If I missed something, sorry :-) I played around the code a bit more (and plan to spend a few more days on it to have some idea how much of the *measurable* change it will make), but I will

[Koha-devel] last hours before string freeze...

2012-04-06 Thread Paul Poulain
Hello koha-devel, Reminder : the string freeze will be declared on monday. I've QAed & pushed all patches that were in "signed-off" status (except some 4 new features submitted by BibLibre that will wait for next release), but I'd like to point that the bug 2780 contains a *lot* of patches that I

[Koha-devel] Kohacon12 - Registrations now open!

2012-04-06 Thread Chris Cormack
Hi All I'm delighted to send this mail (on behalf of the organising team) to let people know registrations for Kohacon12 are now open. http://koha-community.org/kohacon12/registration/ As you probably all know Kohacon is a free conference but we do need people to preregister so we have ideas of

[Koha-devel] Kohacon12 - Sponsorship now open!

2012-04-06 Thread MJ Ray
Hi All I'm delighted to send this mail (on behalf of the organising team) to let people know we are now accepting general sponsorships for Kohacon12, by bank transfer or paypal/card. http://koha-community.org/kohacon12/sponsoring-kohacon12/ As you probably all know Kohacon is a free conference a