Campfire: Dissection

Campfire REALLY intrigues me… Its simple enough, yet the
possibilities are endless once they get the API in place for it.

I’m curious though, how are they handling they load with say 50 campfire
sessions going and 20+ people in each session. There are a lot of
AJAX.Requests going I’m assuming. Seems to me the server should be
getting bogged down on the constant polling from the Campfire
participants. Or do they use some Voodoo to offset this? :wink:

–> Steve

A very good method of reducing the load for a thing like this is to
generate a static XML file. Basically the application updates the XML
file and all the AJAX requests go to that file. That means that the 50
users don’t generate a 50 connections a sec to the DB but only
download a static file that greatly reduces the load. Propably by 80%
or so.

Don’t know if thats the actual way they do things. But I imagine it’s
something similar.

On 6/27/06, Steve W. [email protected] wrote:


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


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

On Jun 27, 2006, at 10:26 AM, Steve W. wrote:

something similar.

Thats actually a really good idea. The only thing is couldn’t you run
into an issue when you go to update the XML file that you could
corrupt
it writing to it when the server is trying to read it out to the
clients
at the same time?

If you wanted to do this the Rails way, you wouldn’t use XML. You
would use YAML instead. But, this is a good pattern to use to
minimize database access._______________________________________________
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Jón Borgþórsson wrote:

A very good method of reducing the load for a thing like this is to
generate a static XML file. Basically the application updates the XML
file and all the AJAX requests go to that file. That means that the 50
users don’t generate a 50 connections a sec to the DB but only
download a static file that greatly reduces the load. Propably by 80%
or so.

Don’t know if thats the actual way they do things. But I imagine it’s
something similar.

Thats actually a really good idea. The only thing is couldn’t you run
into an issue when you go to update the XML file that you could corrupt
it writing to it when the server is trying to read it out to the clients
at the same time?

–> Steve

Bryan L. wrote:

If you wanted to do this the Rails way, you wouldn’t use XML. You
would use YAML instead. But, this is a good pattern to use to
minimize database access._______________________________________________

Actually it seems like it would make more sense to write out to JSON
format than XML or YAML because then the requesting Javascript could
just load up the file and parse it easily.

–> Steve

On 6/27/06, Steve W. [email protected] wrote:

Thats actually a really good idea. The only thing is couldn’t you run
into an issue when you go to update the XML file that you could corrupt
it writing to it when the server is trying to read it out to the clients
at the same time?

To avoid that you write to a temporary file. When It’s done writing
you rename it to the file you intend to share.

On 6/27/06, Steve W. [email protected] wrote:

Actually it seems like it would make more sense to write out to JSON
format than XML or YAML because then the requesting Javascript could
just load up the file and parse it easily.

All that is about reducing load on the client side. Personally I would
prefer a YML file since that can be done with a single line of code.
Model.find_all.to_yaml. Gotta love Rails some days.
Just wondering though. Does anyone know of some JavaScrip parsing
library to convert YAML to arrays or something as simple?

Jon Gretar B. wrote:

All that is about reducing load on the client side. Personally I would
prefer a YML file since that can be done with a single line of code.
Model.find_all.to_yaml.

Model.find_all.to_xml

Jon Gretar B. wrote:

Just wondering though. Does anyone know of some JavaScrip parsing
library to convert YAML to arrays or something as simple?

Model.find_all.to_json

On Tue, Jun 27, 2006, Bryan L. wrote:

If you wanted to do this the Rails way, you wouldn’t use XML. You
would use YAML instead. But, this is a good pattern to use to
minimize database access.

Remember that we’re talking about AJAX calls, though. The X is for XML!
:wink:

As painful as it might be, you’d need to either use XML directly or
transform whatever you wanted into XML. Since we’re talking efficiency,
it doesn’t make sense to do a transformation.

Ben

On 6/27/06, Ben B. [email protected] wrote:

On Tue, Jun 27, 2006, Bryan L. wrote:
Remember that we’re talking about AJAX calls, though. The X is for XML!
:wink:

As painful as it might be, you’d need to either use XML directly or
transform whatever you wanted into XML. Since we’re talking efficiency,
it doesn’t make sense to do a transformation.

Doesn’t matter. The X is there because the request call in Javascript
is called XMLHTTPRequest. However that is just by name. It’s just a
simple http request and nothing in it is related to XML in any way
except by name. I have never gotten a real answer on why they decided
to call it that.

Doesn’t matter. The X is there because the request call in Javascript
is called XMLHTTPRequest. However that is just by name. It’s just a
simple http request and nothing in it is related to XML in any way
except by name. I have never gotten a real answer on why they decided
to call it that.

I always assumed it was because XMLHTTPRequest shipped with IE’s XML
libraries.

I found a good example here:

Search on: chat

Looks like they write to a file called chat.txt by dupming yaml out to
it. I haven’t totally disected all the code yet. It doesn’t however
look like they are pulling directly from the text file but from a Rails
handler in the controller.

On Tue, Jun 27, 2006, Jon Gretar B. wrote:

Doesn’t matter. The X is there because the request call in Javascript
is called XMLHTTPRequest. However that is just by name. It’s just a
simple http request and nothing in it is related to XML in any way
except by name. I have never gotten a real answer on why they decided
to call it that.

I just had a Moment of Enlightenment™! I knew that it was just
XMLHTTPRequest, but I always assumed that it was so-called because it
returned XML.

My ah-ha just now was that HTML can be XML so I was just thinking about
it sideways.

Thanks for the clarification :slight_smile:
Ben

From the interview with Jamis B. on the Ajaxian.com podcast, I
recall him saying they re-wrote the polling component in C. (A very
small portion of the overall app). This allowed the server to handle
many times more load than the Ruby version.


Scott B.
Web D.
Electro Interactive, Inc.