Mongrel users - Aug 2006 - MongrelCluster - How can I make a request to a specific mongrel instance?

In our app we''ve a number of singleton ruby classes that cache static
data
in hashes, things like
string values, system config params, etc).  In a webbrick environment this
works ok, but we find
in production we have a problem because we have 4 caches, one for each
mongrel instance.
 
This also isn''t a BIG problem, but our cache.reload() methods are kinda
useless now, because 
we can''t direct this call to a specific mongrel/rails instance.  
 
Any suggestions?  In the long term, we''ll be redesigning the cache to
be
shared, but we''d like to
fix this now.
 
Had considered writing a quicky "broadcaster" that would iterate over
our
known mongrel ports
and hit them directly.  But we''re not sure if (a) that would work and
(b)
the best way to read the
current running ports.
 
Thanks in advance.
 
Brittain
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060824/2f88ccf3/attachment.html

On 8/24/06, Scott R Brittain <sbrittain at kalivo.com>
wrote:
>
> In our app we''ve a number of singleton ruby classes that cache
static data
> in hashes, things like
> string values, system config params, etc).  In a webbrick environment this
> works ok, but we find
> in production we have a problem because we have 4 caches, one for each
> mongrel instance.
>
> This also isn''t a BIG problem, but our cache.reload() methods are
kinda
> useless now, because
> we can''t direct this call to a specific mongrel/rails instance.
Keep a local cache.  Every minute or five minutes or whatever ask a
master cache shared via drb if it has changed, and if it has, update
the local cache from it.


Kirk Haines

On Aug 24, 2006, at 8:13 AM, Scott R Brittain wrote:
> In our app we''ve a number of singleton ruby classes that cache  
> static data in hashes, things like
> string values, system config params, etc).  In a webbrick  
> environment this works ok, but we find
> in production we have a problem because we have 4 caches, one for  
> each mongrel instance.
>
> This also isn''t a BIG problem, but our cache.reload() methods are
> kinda useless now, because
> we can''t direct this call to a specific mongrel/rails instance.
>
> Any suggestions?  In the long term, we''ll be redesigning the cache
> to be shared, but we''d like to
> fix this now.
>
> Had considered writing a quicky "broadcaster" that would iterate
> over our known mongrel ports
> and hit them directly.  But we''re not sure if (a) that would work
> and (b) the best way to read the
> current running ports.
>
> Thanks in advance.
>
> Brittain

Hey Scott-

	Well you can use pound to setup sticky sessions or session affinity  
but I don''t reccomend that as its fragile. I would say your best  
option is to make a very simple drb server to run your singleton in  
and then all mongrels can talk to the one instance over drb.

-Ezra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060824/5611a13a/attachment.html

On Aug 24, 2006, at 8:13 AM, Scott R Brittain wrote:
> In our app we''ve a number of singleton ruby classes that cache  
> static data in hashes, things like
> string values, system config params, etc).  In a webbrick  
> environment this works ok, but we find
> in production we have a problem because we have 4 caches, one for  
> each mongrel instance.
>
> This also isn''t a BIG problem, but our cache.reload() methods are
> kinda useless now, because
> we can''t direct this call to a specific mongrel/rails instance.
>
> Any suggestions?  In the long term, we''ll be redesigning the cache
> to be shared, but we''d like to
> fix this now.
>
> Had considered writing a quicky "broadcaster" that would iterate
> over our known mongrel ports
> and hit them directly.  But we''re not sure if (a) that would work
> and (b) the best way to read the
> current running ports.
>
> Thanks in advance.
>
> Brittain
Although Drb will probably work, for performance check out memcache:

"memcached is a high-performance, distributed memory object caching  
system, generic in nature, but intended for use in speeding up  
dynamic web applications by alleviating database load."

	http://www.danga.com/memcached/

Ruby library:

	http://www.deveiate.org/projects/RMemCache/

More info:

	http://wiki.rubyonrails.org/rails/pages/MemCached

-John

> In our app we''ve a number of singleton ruby classes that cache
static data
> in hashes, things like
> string values, system config params, etc).  In a webbrick environment this
> works ok, but we find
> in production we have a problem because we have 4 caches, one for each
> mongrel instance.
>
> This also isn''t a BIG problem, but our cache.reload() methods are
kinda
> useless now, because
> we can''t direct this call to a specific mongrel/rails instance.
Why can''t you make request directly to http://localhost:3000 (and 3001,
3002, 3003, etc.) for each mongrel?
> Any suggestions?  In the long term, we''ll be redesigning the cache
to be
> shared, but we''d like to
> fix this now.
Look at memcache... works great for us.
>
> Had considered writing a quicky "broadcaster" that would iterate
over our
> known mongrel ports
> and hit them directly.  But we''re not sure if (a) that would work
and (b)
> the best way to read the
> current running ports.
>
> Thanks in advance.
>
> Brittain
>

On 2006-08-24 08:53:46 -0700, Ezra Zygmuntowicz wrote:
> 	Well you can use pound to setup sticky sessions or session affinity  
> but I don''t reccomend that as its fragile. I would say your best  
> option is to make a very simple drb server to run your singleton in  
> and then all mongrels can talk to the one instance over drb.
why not memcached?

darix

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

On Aug 24, 2006, at 12:38 PM, Marcus Rueckert wrote:
> On 2006-08-24 08:53:46 -0700, Ezra Zygmuntowicz wrote:
>> 	Well you can use pound to setup sticky sessions or session affinity
>> but I don''t reccomend that as its fragile. I would say your
best
>> option is to make a very simple drb server to run your singleton in
>> and then all mongrels can talk to the one instance over drb.
>
> why not memcached?
>
> darix
>
> --  
>           openSUSE - SUSE Linux is my linux
>               openSUSE is good for you
>                   www.opensuse.org
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

	Memcached is indeed another option. Although it sounded like for  
just one Singleton object cache that memcached would be overkill and  
require yet another dependency for the app. DRb is built into ruby  
and is very simple to use. So simple that he could most likely take  
his singleton class and turn it into a drb server in about 4 lines of  
code.

-Ezra

On 8/24/06, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
>
>         Memcached is indeed another option. Although it sounded like for
> just one Singleton object cache that memcached would be overkill and
> require yet another dependency for the app. DRb is built into ruby
> and is very simple to use. So simple that he could most likely take
> his singleton class and turn it into a drb server in about 4 lines of
> code.

I bet I''m not the only person who would like to see those four lines of
code.  Pretty please?  With a cherry on top?

/David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060825/290a165d/attachment.html

> I bet I''m not the only person who would like to see those four
lines of
> code.  Pretty please?  With a cherry on top?
>
> /David
drb is incredibly easy:

http://www.chadfowler.com/ruby/drb.html
http://segment7.net/projects/ruby/drb/


-- 
Rick Olson
http://weblog.techno-weenie.net
http://mephistoblog.com

On 8/24/06, David Vrensk <david at vrensk.com>
wrote:
> On 8/24/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> >
> >         Memcached is indeed another option. Although it sounded like
for
> > just one Singleton object cache that memcached would be overkill and
> > require yet another dependency for the app. DRb is built into ruby
> > and is very simple to use. So simple that he could most likely take
> > his singleton class and turn it into a drb server in about 4 lines of
> > code.
>
> I bet I''m not the only person who would like to see those four
lines of
> code.  Pretty please?  With a cherry on top?
That''s the lovely thing about DRb. It is so very simple to use.

server.rb
-----
require ''drb''
config = {:foo => 1, :bar => ''I am a config''}
DRb.start_service(''drbunix://var/run/drbdemo.sock'',config)
DRb.thread.join
-----

client.rb
-----
require ''drb''
config =
DRbObject.new_with_uri(''drbunix://var/run/drbdemo.sock'')
puts config[:foo]
puts config[:bar]
-----

If I were doing this, I''d leave it nearly that simple if the site was
low use.  DRb is pretty fast.  I have serveral sites with applications
which share some common, low use resources in exactly this way, and it
works wonderfully.

However, if it were going to see a lot of hits, I''d just keep using a
local cache, as I mentioned, and setup a thread to wake up and run
every so often to sync the local cache to the remote one.

If the config object in the drb server has a reload() method or
something like that, any of the clients could trigger a config reload
by just calling it on the DRb object.

Very, very easy to implement.  Works well, and is standard in Ruby.
There''s something to be said for that.


Kirk Haines

On Aug 24, 2006, at 3:52 PM, David Vrensk wrote:
> On 8/24/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
>         Memcached is indeed another option. Although it sounded  
> like for
> just one Singleton object cache that memcached would be overkill and
> require yet another dependency for the app. DRb is built into ruby
> and is very simple to use. So simple that he could most likely take
> his singleton class and turn it into a drb server in about 4 lines of
> code.
>
> I bet I''m not the only person who would like to see those four  
> lines of code.  Pretty please?  With a cherry on top?
>
> /David

Hey David-

	Ok you asked for it ;) Lets make a fake little singleton class to  
simulate what the OP has:

require ''singleton''
require ''drb''

class SingletonDRbCache
    include Singleton
    include DRbUndumped

    # rest of code here
end

DRb.start_service("druby://localhost:11111",
SingletonDRbCache.instance)
DRb.thread.join


	And here is the code you would need to put in environment.rb

require "drb"
DRb.start_service
SingletonDRbCache = DRbObject.new(nil, "druby://localhost:11111")


	Thats pretty much it.


-Ezra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060824/96b8cff0/attachment-0001.html