this implementation isn't optimized in terms of thread creation times.I think that Ruby doesn't do real threading, but in something like Java or .Net, that would have a high cost just in terms of spinning off the new OS threads. You are going to run into issues with the 2 requests per host (which every library has different methods of solving), etc.
On Fri, Oct 3, 2008 at 1:09 AM, Chris Anderson <[EMAIL PROTECTED]> wrote: > Here's a "trivial" implementation of threading for CouchDB access > written in Ruby. > > So far it's been reliable. > > http://github.com/atduskgreg/slipcover/tree/master > > On Thu, Oct 2, 2008 at 2:40 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > > Async, in most languages, is decidedly not trivial. > > > > On Fri, Oct 3, 2008 at 12:37 AM, Troy Kruthoff <[EMAIL PROTECTED]> > wrote: > > > >> Threading bad, agreed. > >> > >> Async good and more trivial. > >> > >> -- troy > >> > >> On Oct 2, 2008, at 1:07 PM, Ayende Rahien wrote: > >> > >> The problem here is not IPC, it is latency. And having to do parallel > >>> reads > >>> tends to be non trivial in many client scenarios (having to do explicit > >>> thread management, not good). > >>> > >>> On Thu, Oct 2, 2008 at 11:04 PM, Chris Anderson <[EMAIL PROTECTED]> > >>> wrote: > >>> > >>> On Thu, Oct 2, 2008 at 12:49 PM, Alan Bell > >>>> <[EMAIL PROTECTED]> wrote: > >>>> > >>>>> Jeremy Wall wrote: > >>>>> > >>>>>> Or you can create a last 5 posts for users view. There is nothing > wrong > >>>>>> > >>>>> with > >>>> > >>>>> that. > >>>>>> > >>>>> But you can't can you? You could create a view of posts for a user > and > >>>>> retrieve the top 5 rows, but you can't control a documents presence > in > >>>>> the view based on the number of other documents that may or may not > be > >>>>> in the view already I think. Maybe I am being overly pedantic here! > >>>>> > >>>>> > >>>> to requote myself: > >>>> > >>>>> > >>>>> Alternatively, how would I have it return only 5 Paste's max for each > >>>>> > >>>> user? > >>>> > >>>>> > >>>>> can't really do that in one request... a request to the map per > human > >>>> with > >>>> > >>>> > startkey=["097337c75773737022bb4e8cd3a92140"]&endkey=["097337c75773737022bb4e8cd3a92140",{}]&count=6 > >>>> would do it. > >>>> > >>>> and to follow up, I agree with Jeremy when he says: > >>>> > >>>> Alternatively, you can do the 20 roundabouts but in parallel so the > >>>>> > >>>> latency > >>>> > >>>>> hit is only the longest roundtrip. CouchDB shouldn't have any problem > >>>>> > >>>> with a > >>>> > >>>>> lot of simultaneous reads at once. > >>>>> > >>>> > >>>> CouchDB handle concurrency well, and shies away from query options > >>>> that would negatively impact it's ability to do so. That means cases > >>>> like this push more work to the client. Maybe the IPC overhead > >>>> outstrips the lower load on CouchDB's internals, maybe it doesn't... I > >>>> guess we'll learn as we go along. > >>>> > >>>> > >>>> -- > >>>> Chris Anderson > >>>> http://jchris.mfdz.com > >>>> > >>>> > >> > > > > > > -- > Chris Anderson > http://jchris.mfdz.com >
