Rails - Jan 2007 - Heavy Database Polling, Optimization question, (for CTI App)

Hi, I''ve done some work intergrating call center software with ruby on
rails.

Specifically I''ve built a login page for our call center reps,  about
every 3 seconds it performs an AJAX query to see if there''s any new
inbound calls.

If there it is, it pop up''s a custom page.

The application runs for 100 users on mongrel rails, (single box) quite
well.
It''s got enough spare capacity to run perhaps 3-500 users at the same
time.

However I want to be able to scale this to around 2-5 thousand reps. (or
more)

Clearly I''ll need to move to a clustered solution.

Here''s an optimization I''d like to make.
Rather then polling the database for each individual user every 3
seconds.

I''d like to have rails it''s self poll more often, but keep an
internal
queue of what needs to be sent out.
When the AJAX connection hits Rails, it checks an internal object,
rather then the database for new actitvity.

Or better yet, when there is new activity it somehow pushes it out the
User, (Avoid the users polling the database).

I suppose I''m looking for some sort of global session variable, that
can
be split across a cluster.
I''m not really sure how to approach this.

Could anyone offer some hints on how to do this?

Worst case,  I can always beef up the database cluster to an extreme,
that''d work, but it just doesn''t seem like the best solution.

- Thanks!

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 1/16/07, David Harkness
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> Hi, I''ve done some work intergrating call center software with
ruby on
> rails.
>
> Specifically I''ve built a login page for our call center reps, 
about
> every 3 seconds it performs an AJAX query to see if there''s any
new
> inbound calls.
>
> If there it is, it pop up''s a custom page.
>
> The application runs for 100 users on mongrel rails, (single box) quite
> well.
> It''s got enough spare capacity to run perhaps 3-500 users at the
same
> time.
>
> However I want to be able to scale this to around 2-5 thousand reps. (or
> more)
>
> Clearly I''ll need to move to a clustered solution.
I''m no expert in this stuff, but my next thought would be using
Memcache.  Of course, do any reading you can on the various ajax chat
services out there.  The folks at lingr.com posted a nice article on
how Lingr works: http://blog.lingr.com/2006/08/lingr_under_the.html
(keywords: jetty, comet).

Campfire still uses http polling, but don''t knock it!  I can go
through wifi resets or trips to the coffee shop, and as soon as my
wifi connects, it continues right where it left off.  Not sure this is
very important for a call center though...

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

--~--~---------~--~----~------------~-------~--~----~
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-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

David Harkness wrote:
> Or better yet, when there is new activity it somehow pushes it out the
> User, (Avoid the users polling the database).
This would be the most scalable. I suggest you look into the various 
Comet implementations to find a solution that will meet your needs.

Eric


--~--~---------~--~----~------------~-------~--~----~
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-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

The industry standard way would be "middleware".

This would be another application, could be rails or not, that your 
clients poll. This "middleware" application then manages, requests to 
your database. This would act as a queue that your clients can poll, 
send requests to, and retrieve requests.

That''s a fairly standard application architecture. A search on 
"middleware architecture" would give some results.

From a rails perspective, I think your rails options would be to run a 
daemon process that answered the client requests and kept an internal 
queue in memory of requests and responses.

You introduce another layer of complexity but scaling is easier.

I remember DHH talking about one of 37 signals products & how they 
scaled the application to meet the demands of thousands of clients 
polling every few seconds.

If I remember rightly, they decided that this was something that rails 
was not suitable for and re-wrote this layer in C.

rgds,
- matt.

David Harkness wrote:
> Hi, I''ve done some work intergrating call center software with
ruby on
> rails.
> 
> Specifically I''ve built a login page for our call center reps, 
about
> every 3 seconds it performs an AJAX query to see if there''s any
new
> inbound calls.
> 
> If there it is, it pop up''s a custom page.
> 
> The application runs for 100 users on mongrel rails, (single box) quite
> well.
> It''s got enough spare capacity to run perhaps 3-500 users at the
same
> time.
> 
> However I want to be able to scale this to around 2-5 thousand reps. (or
> more)
> 
> Clearly I''ll need to move to a clustered solution.
> 
> Here''s an optimization I''d like to make.
> Rather then polling the database for each individual user every 3
> seconds.
> 
> I''d like to have rails it''s self poll more often, but
keep an internal
> queue of what needs to be sent out.
> When the AJAX connection hits Rails, it checks an internal object,
> rather then the database for new actitvity.
> 
> Or better yet, when there is new activity it somehow pushes it out the
> User, (Avoid the users polling the database).
> 
> I suppose I''m looking for some sort of global session variable,
that can
> be split across a cluster.
> I''m not really sure how to approach this.
> 
> Could anyone offer some hints on how to do this?
> 
> Worst case,  I can always beef up the database cluster to an extreme,
> that''d work, but it just doesn''t seem like the best
solution.
> 
> - Thanks!

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Wow, a lot of great advise, and places to start looking, thanks all!

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---