On Saturday 17 May 2008 14:07, Daniel Cheng wrote: > On Sat, May 17, 2008 at 7:06 PM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > > On Saturday 17 May 2008 06:24, Ian Clarke wrote: > >> On Fri, May 16, 2008 at 11:40 PM, Daniel Cheng > >> <[EMAIL PROTECTED]> wrote: > >> > On Sat, May 17, 2008 at 7:29 AM, Matthew Toseland > >> > <[EMAIL PROTECTED]> wrote: > >> >> Ian and I have eventually come to the conclusion that we should include > > db4o, > >> > >> Yay. > >> > >> >> Of course there will be latency here when objects are > >> >> not cached, so we will need to cache a few request choices in advance for > >> >> each RequestStarter. And we will need to devise some way to deal with > >> >> requests that don't want to be persisted - presumably we'd keep them in > > RAM. > >> > > >> > Please don't. > >> > According to what I have read, db4o should be good enough to use directly: > >> > >> I agree with Daniel, DIY may be an admirable quality when it comes to > >> home and car repair, but not with software. > >> > >> One of the benefits of using third-party stuff like db4o is that we > >> can outsource problems to people far more focussed on the solutions to > >> those problems than we can afford to be. > >> > >> If we spot a problem, we should fix it, but let's not fall into the > >> "premature optomization" trap. > > > > Which part of my proposal are you both criticising? > > > > If it's the "we should cache a few request choices in advance" bit then I > > stand by that. Any database query (assuming the working set is large) will > > involve many dependant disk accesses. > > Did you read my original post? There were three features in db4o to > offload that a bit... CachedIoAdapter, prefetching, weakreferences .. > see my previous post for details on that.
Strictly speaking this is prefetch we're talking about, not caching. > > > We have to send a request roughly every > > 800ms on my node (for SSKs). With slow commodity drives, often with other > > disk load going on, and with fairly complex database accesses involving > > multiple tables and therefore *many* mostly dependant seeks, we are not going > > to reliably meet that deadline no matter how good the database is. I will add > > a statistic for this, but my system is massively overpowered for this sort of > > effect, so we will need to test it on volunteers' slow systems. > > > > If it's the "requests that don't want to be persisted", what would you do with > > fproxy requests and other non-persistent requests? Store them to disk anyway?
pgpcuqy4VAHBq.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
