Heavy Database Polling, Optimization question, (for CTI App)

Rails
#1

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!
#2

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 H. 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!
#3

David H. 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

#4

On 1/16/07, David H. [email protected] wrote:

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 O.
http://weblog.techno-weenie.net
http://mephistoblog.com

#5

David H. wrote:

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

Hi there,

Here is some more info on memcached. Memcache is a scalable memory-based
cache that can be used in a cluster setup. Memcache can really take the
load off or your database.

http://en.wikipedia.org/wiki/Memcached

I would also check out backgroundrb. backgroundrb could run a job every
second to query the db and put the result in memcached.

Sincerely,
Jason E.

#6

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