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