Hello RonR -Talk
Where should I look for connection pooling for Ruby DB access and also connection pooling for ActiveRecord access ?
Are there any examples available ?
Maurice Yarrow
Where should I look for connection pooling for Ruby DB access and also connection pooling for ActiveRecord access ?
Are there any examples available ?
Postgres only, and outside of Rails, but you might find pgpool interesting.
Hello Philip
Only Postgres ? Do I correctly understand your response to mean: within Rails/ActvRecd, ONLY Postgres has connection pooling support ?
If this is so, this is NOT good news for MySql access: Why ? Because opening plus closing a MySql connection via Ruby with mysql-2.7 interface takes 6 milliseconds (4.5 millisec for postgres with postgres-0.7.1 interface). This was timed out of Ruby using Time.new, so I have to assume this is a correct number.
If connections cannot be reused for next page access, this 6 milliseconds cost right there means that a maximum of 167 pages can be served a second, and this does NOT even include dynamic page generation cost !!! Whew !
Please, someone talk me out of these numbers !
Maurice Yarrow
Philip Hallstrom wrote:
Hi,
Sounds like you might be a java refuge. The concept of connection pooling is not part of Rails. A Rails application is single-threaded and to handle multiple users you need to run multiple copies of your Rails application. This might seem a bit foreign. However, these days most new Rails apps will use a cluster of Mongrel instances in production and it works quite well. Each one of them will have its own dedicated connection to the db and all session management will be done external to the app, most likely in the db itself or in a shared cache.
-Eric
Eric
Yes, actually, I host my own server at home which I have set up with a fairly progressive configuration:
Pound-2.1.3 front end / load balancer forwards to: 3 Mongrel_rails clusters of 3 mongrels each (i.e., there are 3 rails apps), Apache 2.1.3, with mod_perl, mod_php, Apache::ASP (perl-script), and tomcat 5.0.28 (running 2 different apps, plus three other development hosts)
also postgres 8.1.4 mysql 5.0.19
Anyhow, it is reassuring (considering my question) to hear you say that each Mongrel keeps its own open db connection. I was not aware of this and I am glad you could explain this to me.
Of course, me being from Missouri ("show me" state), I'll probably now go off and apply the same timing tests out of my Rails apps. (Prior timing tests were with command-line Ruby only)
Thanks for this consise explanation
Maurice Yarrow
Eric Knapp wrote:
Eric
(errata to previous: typo correction) The Apache I run is 2.2.3 (not 2.1.3, but the pound is 2.1.3, not that it particularly matters...)
Maurice Yarrow
Maurice Yarrow wrote:
Hello Philip
Only Postgres ? Do I correctly understand your response to mean: within Rails/ActvRecd, ONLY Postgres has connection pooling support ?
Sorry... I meant that the application I linked to only works for PostgreSQL.
And it's independant of Rails... it would work for anything that can connect to a Postgresql databse.
If this is so, this is NOT good news for MySql access: Why ? Because opening plus closing a MySql connection via Ruby with mysql-2.7 interface takes 6 milliseconds (4.5 millisec for postgres with postgres-0.7.1 interface). This was timed out of Ruby using Time.new, so I have to assume this is a correct number.
If connections cannot be reused for next page access, this 6 milliseconds cost right there means that a maximum of 167 pages can be served a second, and this does NOT even include dynamic page generation cost !!! Whew !
Once a connection is opened in Rails it stays open through the life of the server process so you're only opening a connection once per server startup.