http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13431
--- Comment #11 from Jacek Ablewicz <[email protected]> --- (In reply to Tomás Cohen Arazi from comment #9) > I guess for most of the cases mysql does a better job caching query results. It looks that way - fastmmap turns out to be not all that fast after all ;). I did some simple tests (fetching BKS framework with GetMarcStructure() 1000 times in the row): - not using Koha::Cache, mysql query cache enabled: 27 seconds - not using Koha::Cache, mysql query cache disabled: 39s - fastmmap_cache: 35s (!) - memory_cache: 10s However, such test case is pretty artificial - things may be different for syspref caching, authorized values caching, how would it behave on heavily loaded servers, what kind of impact from connection latencies we may expect if persistent caching is not in use and mysql is on the different machine (I guess quite a big impact regarding sysprefs and AVs fetching?) etc. On the other hand, I wonder how many people in the wild may be actually using CACHING_SYSTEM=fastmmap_cache (or are even aware of such possibility)? Interesting thing about fastmmap_cache is that it is currently never used by default nor as a fallback mechanism (at least not since Bug 12041). But it still gets loaded and initialized each and every time, causing possible "Permision denied ..." issues even on such setups which do not use fastmmap cache at all. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
