> I was thinking about this also. There is a nsmemcache module for > naviserver, but it uses some of the C apis that have been changed > slightly in naviserver, so it doesn't work with aolserver, but it > shouldn't be difficult to port.
memcached is lovely, but what makes ns_cache so fast is that it runs in-process as a function call, and thus suffers no networking overhead. If it were database (or dbm) backed, that'd be great. What I was thinking was using ns_cache on your own machine, but with a background "sync" thread that informed other aolserver instances of changes, so the various aolserve's ns_caches stayed in sync. That'd be small and compact, and fairly foolproof. I currently use BerkeleyDB for this on bookmooch, but the multi-machine syncing in bdb is very heavyweight and confusing as all hell, but it is at least peer-to-peer, so new aolserver instances can come die or come up, and in theory it all works. But.. the zero-latency of a function call cache lookup (vs memcached) is so crazy good that it makes it worth it. With MoodMixes, I use ns_cache to do several hundred lookups per html page, when running pages in non-english (ie, each phrase is looked up). The network latency of a network-based cache wouldn't really work, unless I go the much-more-complicated route of massive async concurrent lookups. The dci stuff appears to be nicely thought out, but personally I wouldn't use it, as all the cache operations appear to be client/server, and thus incur a latency overhead. -john ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
