Correct me if Im wrong, but do you think its caching triplet is a waste of resource and making the whole thing much slower ??
My understanding of caching : storing frequently accessed data in ram to reduce the time required to read that data if the data ever get requested again. I dont think it will do any good since triplet is always different, and on average a single unique triplet will only get hit twice a day. Even on memcache website it says : "On a high-traffic site with updates happening many times per second, this makes the the cache practically worthless. In fact, it's often harmful to have it on, since there's a overhead to maintain the cache" I think locking issue during cleanup can be avoided by changing table type to InnoDB since InnoDB has better locking mechanism than MyISAM. (I dont recommend you to change yet as policyd is not yet compatible with InnoDB). Rianto Wahyudi --- adela putri tirta belek On 9/7/07, Oliver Eales <[EMAIL PROTECTED]> wrote: > > Cami Sardinha schrieb: > Artem Bokhan wrote: > > > Hello again. > > Did anybody make any efforts to make policyd or some of its parts to > work with memcache? > > There has been no requirements/requests from anyone for such > functionality. > > I think that this is basically a good idea. I would apreciate such a > feature as it could improve the speed dramatically. > The main problem is the memory usage on a high-load db system. > > As our policyd table are about 15 GB i dont know how i could be kept im > memory. > > Regards, > > Oliver Eales > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > policyd-users mailing list > policyd-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/policyd-users > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ policyd-users mailing list policyd-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/policyd-users
