From: ahoward <ahoward@...>
Date: 2003-01-31T13:44:47+09:00
Subject: Re: drb experts

On Fri, 31 Jan 2003, Eric Hodel wrote:

> Here I meant client and server processes.

me too.

'well, the client and server will be the same in my case'.gsub
  /will be the same/, 'will be on the same host/'


> Anything you write to should have a mutex around it, unless you don't care
> about lost updates.

you mean anthing outside the local scope of the method called?

eg. @var, @@var, $var, etc.

> Let me clear this up with a little code:
[code very helpfull - thanks!!!]

> When you use Undumped, DRb passes a proxy of the object across to
> the client, so everything done through the object takes place on
> the server side, not the client side.  The client only needs to load
> DRb.

ahhh.  i wondered if this were the case.  can anyone explain the 'un' in
UnDumped?  'un' becaues it is not actually dumped, but proxies are returned
instead?

> If you don't use Undumped, you need to load all the libraries used by the
> class on the client side.

in my case - the cgi process would need postgres.so, etc.

> For a DB driver, this would be the postgres drives, and you'd get the whole
> driver on each Apache process.  The more Apache processes you have, the more
> overhead this takes up.

as i mention above, the client and server side would be the same in my case,
since the cgi (client) would be using a pool (server) running on my web/db
server machine(s).  i wonder though, if in this case the cost would actually
be that high as you think since postgres.so would be shared for all processes
- surely 'require' does a shared mapping and not a private one?

in fact, it seems like in the case of using the client and server on the same
machine - at least where *.so's are concerned - there would be little
differnce in overhead since the one image would be in memory regardless.  have
you done any performance tests of this situation?

-a


thanks again for the code.

>
> Here is an example:
>
> ---
> server.rb:
>
> require 'drb'
> class Server
>   def custom_obj
>     return CustomObj.new
>   end
>   def custom_undumped_obj
>     return CustomUnDumpedObj.new
>   end
> end
> class CustomObj
>   def do_stuff
>     puts "I'm doing stuff!"
>   end
> end
> class CustomUnDumpedObj
>   include DRbUndumped
>   def do_stuff
>     puts "I'm doing stuff, and I'm not dumped!"
>   end
> end
> DRb.start_service('druby://localhost:5000', Server.new)
> DRb.thread.join
>
> ---
> client.rb:
>
> require 'drb'
>
> class CustomObj
>   def do_stuff
>     puts "I'm doing stuff!"
>   end
> end
>
> DRb.start_service
> obj =3D DRbObject.new(nil, 'druby://localhost:5000')
> co =3D obj.custom_obj
> udo =3D obj.custom_undumped_obj
> p co
> p udo
> co.do_stuff
> udo.do_stuff
>
> ---
>
> If you start up the server, then run the client you will see:
>
> ** client side:
> $ ruby client.rb
> #<CustomObj:0x8056f28>
> #<DRb::DRbObject:0x8056b18 @ref=3D67286072, @uri=3D"druby://localhost:5000">
> I'm doing stuff!
>
> ** server side:
> $ ruby server.rb
> I'm doing stuff, and I'm not dumped!
> ^C
> $
>
> If you remove the class CustomObj from the client.rb you get this:
>
> ** client side:
> $ ruby client.rb
> /usr/local/lib/ruby/site_ruby/1.6/drb/drb.rb:123:in `load': undefined class=
> /module CustomObj (ArgumentError)
>         from /usr/local/lib/ruby/site_ruby/1.6/drb/drb.rb:123:in `load'
>         from /usr/local/lib/ruby/site_ruby/1.6/drb/drb.rb:166:in `recv_repl=
> y'
>         from /usr/local/lib/ruby/site_ruby/1.6/drb/drb.rb:300:in `send_mess=
> age'
>         from /usr/local/lib/ruby/site_ruby/1.6/drb/drb.rb:227:in `method_mi=
> ssing'
>         from /usr/local/lib/ruby/site_ruby/1.6/drb/drb.rb:226:in `open'
>         from /usr/local/lib/ruby/site_ruby/1.6/drb/drb.rb:226:in `method_mi=
> ssing'
>         from client.rb:15
>
> So the advantage of using include UnDumped is that everything gets
> proxied, there's less per-process overhead because you don't have a
> driver sitting in each process, and you have perfect control over the
> number of DB sockets you have open.
>
> The disadantage is that you're shoving everything into a bitty socket
> before sending it out to the DB.
>
> --=20
> Eric Hodel - drbrain@segment7.net - http://segment7.net
> All messages signed with fingerprint:
> FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04
>
>
> --/qIPZgKzMPM+y5U5
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (FreeBSD)
>
> iD8DBQE+OeJ/MypVHHlsnwQRAnR1AJ9md6MuEXaP2kU8bQtQilYrzybGOwCgitrS
> Q/Z9xVuRU3qW08Lq4RxOAyk=
> =WC7o
> -----END PGP SIGNATURE-----
>
> --/qIPZgKzMPM+y5U5--
>
>

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================