On Saturday 17 May 2008 14:07, Daniel Cheng wrote: > On Sat, May 17, 2008 at 7:06 PM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > On Saturday 17 May 2008 06:24, Ian Clarke wrote: > >> On Fri, May 16, 2008 at 11:40 PM, Daniel Cheng > >> <j16sdiz+freenet at gmail.com> wrote: > >> > On Sat, May 17, 2008 at 7:29 AM, Matthew Toseland > >> > <toad at amphibian.dyndns.org> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080517/9a41bebe/attachment.pgp>
