Forum: Ruby on Rails Performance with many look-up tables

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Eric S. (Guest)
on 2006-03-09 01:27
(Received via mailing list)
Hi,
I have an app - a first cut ROR - so it's a bit of a mess. I'm now
trying to clean it up. The app relies on a heap of look-up tables that
are, by and large, static. I'm wondering where and how to initialise
these collections once - so that I don't have to keep hitting the
database every time I start a new action.

Can I initialise the collections at the start of a session - say in the
application controller - and have them persist for the whole session?

Cheers,
Eric.
zdennis (Guest)
on 2006-03-09 05:32
(Received via mailing list)
Eric S. wrote:
> Hi,
> I have an app - a first cut ROR - so it's a bit of a mess. I'm now
> trying to clean it up. The app relies on a heap of look-up tables that
> are, by and large, static. I'm wondering where and how to initialise
> these collections once - so that I don't have to keep hitting the
> database every time I start a new action.
>
> Can I initialise the collections at the start of a session - say in the
> application controller - and have them persist for the whole session?
>

If the lookup tables are application-wide (ie, they don't rely on userA
being logged in with a
session) you can stored them in a class variable on your controller.
During the dispatch.fcgi
process existance they will exist. For each new dispatch.fcgi process
that starts up, it will
require to load the lookup table information. This is probably your
optimal solution.

You don't want to store them in an instance variable on the controller
though because for each new
request you will be getting new instances of your controllers.

If you have alot of data in your lookup tables and you don't want to
have to keep the same data
around for every dispatch.fcgi process running you can you could create
a UNIXSocket server where
you house the data, and have your controller's communicate to that via
UNIXSocket Although this may
be overkill. =) For cross-platform compatibility you could use a TCP
Server, and connect via a
TCPSocket, but that up to you!

Zach
Ben M. (Guest)
on 2006-03-09 08:15
(Received via mailing list)
zdennis wrote:
> If you have alot of data in your lookup tables and you don't want to
> have to keep the same data around for every dispatch.fcgi process
> running you can you could create a UNIXSocket server where you house the
> data, and have your controller's communicate to that via UNIXSocket
> Although this may be overkill. =) For cross-platform compatibility you
> could use a TCP Server, and connect via a TCPSocket, but that up to you!

Or, as someone on the list pointed out to me a while back, you can use
DRb[1] to make the
static data available to all your processes.

b

[1]http://www.chadfowler.com/ruby/drb.html
Eric S. (Guest)
on 2006-03-10 08:13
(Received via mailing list)
Thanks Guys for the responses - I kinda assumed this would be a trivial
question (and probably is) but I obviously have a lot to think through
here. I'm temptd by the Drb solution, but I wonder if this has
maintenance implications down the track. If I go with the
@@class_variables do I have a load once per session outcome?

I'm a little new at this web programming gig, so forgive my ignorance.
CHeers,
Eric.
Mike G. (Guest)
on 2006-03-10 10:29
(Received via mailing list)
You could also have a look at the enumerations plugin

http://www.somethinglearned.com/articles/2005/10/2...


Eric S. wrote:
> Ben M. wrote:
>>
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>


--
Mike G.                email : removed_email_address@domain.invalid
Technical Director          fax   : +353 68 470 01
XL CRS                      mobile: +353 87 677 2055
Lisselton                   phone : +353 68 470 10
Listowel
Co. Kerry                   MSM   : removed_email_address@domain.invalid
Ireland                     Y!M   : removed_email_address@domain.invalid
This topic is locked and can not be replied to.