[Koha-devel] [Koha-patches] [PATCH] Removed RSS Option from UI

[Joe Atzberger]

While it is the obvious "core" of DB access in Context, it is not the only
target for memcached efficiency, in my mind.  That is because the access is
rather straight-forward retrieving preferences (that are already cached for
the process by Koha).

To me, the best targets are the sections that require a lot of computation
to build an otherwise static object, like MARC frameworks or a fully parsed
MARCXML object.  The reason the caching should be "better" there is because
it skips both disk and CPU loads, and the data is in a more highly processed
state.  The speed of retrieving a syspref like marcflavour won''t matter as
much because when you already have the correct object built, you don't need
to check it.  Or that's the idea, anyway...

--Joe

On Wed, Feb 4, 2009 at 6:14 AM, paul POULAIN <paul.poulain at biblibre.com>wrote:

> John Beppu a écrit :
> > I agree that it was quite a disappointment to only see about 10%
> > improvement in the request rate despite eliminating so many database
> > queries.  I was expecting a much bigger speed increase, too.
> my bet is that C4::Context cleaning will be the best improvement source.
> As Frederic D. has already pointed, each page call read something like
> 26 times the config.xml, a lot of sessions are created on mySQL...
> Marc C. at BibLibre spend some time on that but could not succeed yet.
> It's still on his roadmap though.
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20090204/4dfba0e7/attachment-0003.htm>