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. > 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? > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
