On 2006.09.30, John Buckman <[EMAIL PROTECTED]> wrote: > >What you can consider doing is using the new nsproxy module to use the > >BDB Tcl binding from nstclsh in separate processes in a nsproxy pool. > >Then, you're relying on BDB's "concurrency" (multi-process locking) > >being implemented correctly. > > Yes, I prototyped exactly that, and it worked, and yield only a 4x > slowdown in database fetch time, rather than the 18x slowdown that > the RPC mechanism yielded. However, I probably won't initially use > that technique, as I first want to see where the bloat problem is.
Uh, if you use nsproxy to push the BDB access out to a proxy pool, it'll help you isolate the problem, won't it? nsproxy pools are pools of separate processes. If you push your BDB accesses out to a nsproxy pool, but your nsd memory footprint still grows, then you know the issue is elsewhere in your code that's still running in your main nsd. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
