Wojciech Zatorski a écrit :
> Witaj Chris,
>
> W Twoim liście datowanym 30 czerwca 2008 (21:03:31) można przeczytać:
>> Or indeed both memcached and mod_perl :)
> btw: using Koha without mod_perl is bg efficiency mistake.. ;)
does it mean you use Koha 3.0 with mod_perl currently ? and you don
Chris C. did some tests with memcached and it seems it's a great way to
improve perfs of Koha.
However, it requires some code changes. And an additionnal software
installed on the server (memcached is provided on debian, and mandriva
-contrib-, so it's probably not a true problem)
I suggest th
Hello Paul,
Tuesday, July 1, 2008, 9:51:56 AM, you wrote:
PP> does it mean you use Koha 3.0 with mod_perl currently ? and you don't
PP> have any problem with it ? That would be good to know...
nop.. i still using Koha 2.2.x with PerlResponseHandler
ModPerl::RegistryPrefork,
version 3.0 is still
Hello,
With 3.0RC1 done, git should now have only bugfixes.
So I think it's time for a 3.2 branch.
I have no idea of how it can be done with git. Should be have 2 separate
repos ? only one with a git checkout -b rel_3_2 origin/rel_3_2 locally
to point on branch rel_3_2 ? That's probably the way
On Tue, Jul 1, 2008 at 9:17 PM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> Hello,
>
> With 3.0RC1 done, git should now have only bugfixes.
> So I think it's time for a 3.2 branch.
>
> I have no idea of how it can be done with git. Should be have 2 separate
> repos ? only one with a git checkout -b r
Galen Charlton a écrit :
> Hi,
>
> As noted in bug 2171
> (http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2171), the
> transfers to-do report is not working. The intention of the report
> seems to be:
>
> * get a list of hold requests grouped by branches; specifically, those
> that alread
Chris Nighswonger a écrit :
> Hi all,
> I'm currently working on Bug 2008 involving the circulation report
> entitled "Daily Reconciliation." What I'm looking for is any kind of a
> specification outline for this report. The current code is quite broken.
> A little research in the wiki seems t
"Andrew Moore" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 30, 2008 at 8:05 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> > (Note : It should not have been added to 3.0 imo)
>
> Yes, I recognize that we don't have unanimous agreement on this. I
> sent out several messages about my work in advance to t
On Tue, Jul 1, 2008 at 3:06 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> I suggest that we add memcached option to Koha 3.2.
I think this is a great idea.
How will this interact with mod_perl if we were to add a mod_perl
option for 3.2 (or beyond)?
-Andy
Hi MJ -
On Tue, Jul 1, 2008 at 6:42 AM, MJ Ray <[EMAIL PROTECTED]> wrote:
> The original message stated pretty clearly that they wouldn't be
> applied as-is, then "essentially these same patches" were submitted
> and apparently applied without question. That stung.
I didn't get much feedback on
Profiling an OPAC search with dprofpp -I gives this result:
Total Elapsed Time = 4.046462 Seconds
User+System Time = 3.676462 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
38.6 0.008 1.420 1 0.0081 1.4195 C4::Search::searchResults
35.6 0.030 1.310
Andrew Moore a écrit :
> On Tue, Jul 1, 2008 at 3:06 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
>> I suggest that we add memcached option to Koha 3.2.
>
> I think this is a great idea.
>
> How will this interact with mod_perl if we were to add a mod_perl
> option for 3.2 (or beyond)?
mod_perl =
This is just a reminder that I'm working to consolidate the three
misc/cronjobs/overduesnotices*.pl programs. From what I can tell two
of them are nearly identical, but don't really work, and the third
doesn't add enough extra functionality to justify a separate program.
I expect to send out a prop
> mod_perl = x3 improvement
> memcache = x2 improvement
>
> so :
>
> both = x6 improvement
>
> lol. I agree that's only theory.
>
> A quick question again : did someone experiment mod_perl recently ? it
> used to work pretty well something like 1 year ago.
It works perfectly for OPAC. I didn't te
On Tue, Jul 01, 2008 at 09:51:56AM +0200, Paul POULAIN wrote:
> Wojciech Zatorski a écrit :
> > btw: using Koha without mod_perl is bg efficiency mistake.. ;)
>
> does it mean you use Koha 3.0 with mod_perl currently ? and you don't
> have any problem with it ? That would be good to know...
>
Frederic Demians <[EMAIL PROTECTED]> wrote:
> Profiling an OPAC search with dprofpp -I gives this result:
>
> Total Elapsed Time = 4.046462 Seconds
> User+System Time = 3.676462 Seconds
> Inclusive Times
> %Time ExclSec CumulS #Calls sec/call Csec/c Name
> 38.6 0.008 1.420 1 0.0081 1.
Hi,
On Tue, Jul 1, 2008 at 1:06 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> If you agree with this proposal, i'll add it to RFC for 3.2
I agree with pursuing both memcached and mod_perl for 3.2.
Regards,
Galen
--
Galen Charlton
Koha Application Developer
LibLime
[EMAIL PROTECTED]
p: 1-888-56
Hi,
On Tue, Jul 1, 2008 at 1:06 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> - memcache some other tables, that are often used : branches, itemtypes,
> auth_types, biblio_framework, categories, cities, ethnicity, opac_news
In particular, caching the entire set of active MARC frameworks would
be
Hi,
On Tue, Jul 1, 2008 at 6:22 AM, Frederic Demians <[EMAIL PROTECTED]> wrote:
> By the way, isn't memcached out of proportion. mod_perl has
> session/global variables. That would be enough to cache syspref and
> other application-level variables.
We should experiment, of course. Even if mod_pe
> These %s add up to considerably more than 100% don't they? What does
> that mean?
This is a dprofpp -I result. It means that it displays subroutine times
inclusive of child subroutine times. I suppose for example that
C4::Context::new call C4::Context::read_config_file that call
XML::Simple:
Hi,
On Tue, Jul 1, 2008 at 2:17 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> With 3.0RC1 done, git should now have only bugfixes.
> So I think it's time for a 3.2 branch.
>
> I have no idea of how it can be done with git. Should be have 2 separate
> repos ? only one with a git checkout -b rel_3_2
Frederic Demians <[EMAIL PROTECTED]> wrote:
> So reading config file may be not so slow but it is called 23 times! If
> you add a warning in this procedure, you see it is called from those
> modules: [...]
Why isn't it as simple as caching the result, as in
diff --git a/C4/Context.pm b/C4/Conte
Hi,
On Tue, Jul 1, 2008 at 9:06 AM, MJ Ray <[EMAIL PROTECTED]> wrote:
> Frederic Demians <[EMAIL PROTECTED]> wrote:
>> So reading config file may be not so slow but it is called 23 times! If
>> you add a warning in this procedure, you see it is called from those
>> modules: [...]
>
> Why isn't it
Hi
2008/7/1 Galen Charlton <[EMAIL PROTECTED]>:
> Hi,
>
> > I think so. I don't recall setting up XSLT explicitly, but I've
> > certainly had errors about invalid marcxml spat at me.
>
> Right; because all MARC records are processed through MARC::File::XML
> at various points, there will be XML p
24 matches
Mail list logo
