David Vallner wrote:
> Ben Johnson wrote:
>> What do you mean by the DNY lookup is asynchronous and will block my 
>> process? If I was to call curl directly from the command line using 
>> `curl` in ruby wouldn't that be much faster. In this instance it wo uld 
>> get it's own process and take better advantage of a dual processor 
>> system. Am I correct, because what I planned on doing was just using 
>> curl directly from the command line unless there is a downside to this.
> 
> Odds are the process startup would take up more time than you'd gain.
> IMO that's NOT a good way to leverage a dual-core processor. Doing hacks
> like this only makes sense in a CPU-intensive application (which curl
> hardly is), and you want to split the work between two (or maybe more)
> *threads* more or less equally. You also want these threads being
> managed in a thread pool to avoid OS thread initialisation time. For
> added hilarity, you need native threads for this, not green threads -
> the OS can't schedule those on different cores.
> 
> Technically, you could do this using processes instead of threads.
> Except once again, you want to outweigh the process initialisation time,
> and the time it takes to transfer data between the processes, with the
> added performance eliminating context switches brings. Which just might
> not be all that easy.
> 
> David Vallner

Thanks for your response.

I just implemented curl using `curl`. I would say I have about 60 - 100 
simulatneous requests going out at the same time. With the switch 
between Net::HTTP to using `curl` I noticed a speed increase of almost 3 
times. Either Net::HTTP is slow or ruby is slow, but something in 
Net::HTTP is slowing it down quite a bit.

-- 
Posted via http://www.ruby-forum.com/.