Well!  That explains a lot. :)

This was all in development mode.  As slow as it is in development
mode, I'd never release it to production.  Fortunately, for reasons
you explained above, it does not suffer the same performance problems
in production mode.

I suppose since previously I was only working with the one database,
that connection was maintained outside the scope of caching/non-
caching models.  But with this new connection defined and used within
a model, the non-caching must have been causing a new connection to
happen on each use.

Thanks for your time and knowledge.


On Sep 22, 3:11 pm, Michael Schuerig <mich...@schuerig.de> wrote:
> On Wednesday 22 September 2010, michael_teter wrote:
>
> > I tested this in production mode, and it's _much_ faster.  It's fast
> > enough that I'm almost certain that it's not reconnecting to the
> > secondary database each time (at least in production mode).  I don't
> > know if it's just overhead of other development behaviors or if it's
> > actually doing things differently (with respect to connections/pools/
> > reconnects); and I don't have time to investigate deeper.
>
> Did you originally write that your problem is with behavior in
> development environment? I was assuming production. The reason for the
> behavior you notice is simple: In development environment, class caching
> is disabled, in other words, classes are reloaded on each request so
> that changes are immediately effective. An intended consequence is that
> class variables and class instance variables (i.e., instance variables
> of class objects) are re-initialized again, too. Among those being the
> variables that hold the database connection.
>
> Michael
>
> --
> Michael Schuerig
> mailto:mich...@schuerig.dehttp://www.schuerig.de/michael/

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to rubyonrails-t...@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en.

Reply via email to