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

[Rick Welykochy]

Joe Atzberger wrote:

> 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...

This harks back to installing an ORM like DBIx::Class into Koha.

On the last ORM project I worked on, we implemented one layer of abstraction
between perl's DBI and the app itself. Within that layer, we could flag
*any* table as being read-only and/or cache-able. With this feature, caching
and the attendant increase in efficiency was available to the app without
having to change a single line of app code.

This is a good reason to provide an abstraction layer between the ORM we
end up using and the Koha app. In that layer we can do things like cache,
as well as capture metrics (very usfull for optimisation).

Of course, a cache is pretty useless unless perl itself is cached using
mod_perl or similar.

Food for thought for Koha's future ORM.


cheers
rickw



-- 
_________________________________
Rick Welykochy || Praxis Services

Maybe this world is another planet's Hell.
      -- Aldous Huxley