From: Eric Hodel <drbrain@...7.net>
Date: 2003-01-31T11:42:09+09:00
Subject: Re: drb experts


--/qIPZgKzMPM+y5U5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

ahoward (ahoward@fsl.noaa.gov) wrote:

> > This will work well if you can load all the database drivers on the cli=
ent
> > end (once per client), and will perform the best because DRb is only
> > dispatching database connections.
>=20
> well, the client and server will be the same in my case - i plan to use t=
his
> object from cgi programs.

Here I meant client and server processes.

> > This will result in the least memory overhead, but DRb may become a
> > bottleneck if you have to do alot of database activity.  Remember DRb s=
pawns
> > a thread per request.
>=20
> yes, this does seem like a bottle neck.  in general, what types of data n=
eeds
> thread protection when programming drb?

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

For a DB driver, that would probably be the open DB socket count.

> > Well, if you have only a few database requests, or have low memory, go
> > with option b.  If you have a ton of memory, or are doing many database
> > queries, go with option a.
>=20
>=20
> 2GB or 512GB of RAM - primary/secondar ha-linux machines.
>=20
> > If you're going to be using this with Apache, you'll be a tough call.  =
Is
> > the overhead of having the PG drivers in each Apache process worth it?
> > Probably yes if you have a ton of memory or don't have many Apache proc=
esses
> > hanging around.  If you are low on memory, or only do a few DB queries/=
page,
> > then you may be better off having DRb handle everything.
>=20
> you lost me.
>=20
> why would the pg drivers be loaded into apache in either case?  i'm
> envisioning a pool which fires up idependently from cgi programs or apach=
e,
> cgi programs will either get a proxy object delegating calls to the drb o=
bject
> which _does_ have the drivers loaded, or a handle (guess this is a proxy =
too
> ;0) to the actuall connection object.  in either case it seems like only =
the
> server(s) would have the postgresql.so in memory?  i'm not using mod_ANYT=
HING.

Let me clear this up with a little code:

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.

If you don't use Undumped, you need to load all the libraries used by
the class on the client side.  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.

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--