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? ;-) --> Steve -- Posted via http://www.ruby-forum.com/.
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. <racer99@hotmail.com> wrote:> 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? ;-) > > --> Steve > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/
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 -- Posted via http://www.ruby-forum.com/.
On Jun 27, 2006, at 10:26 AM, Steve W. wrote:> 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?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.
Bryan Liles 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 -- Posted via http://www.ruby-forum.com/.
On 6/27/06, Steve W. <racer99@hotmail.com> 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. <racer99@hotmail.com> 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 Borgthorsson http://www.jongretar.net/
Jon Gretar Borgthorsson 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 Borgthorsson 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 Liles 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! ;) 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 Bleything <ben@bleything.net> wrote:> On Tue, Jun 27, 2006, Bryan Liles wrote: > Remember that we''re talking about AJAX calls, though. The X is for XML! > ;) > > 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. -- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/
> 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. -- Posted via http://www.ruby-forum.com/.
I found a good example here: http://www.codecite.com/main/projects 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. -- Posted via http://www.ruby-forum.com/.
On Tue, Jun 27, 2006, Jon Gretar Borgthorsson 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(tm)! 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 :) Ben
>From the interview with Jamis Buck on the Ajaxian.com podcast, Irecall 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 Becker Web Developer Electro Interactive, Inc. http://www.ElectroInteractive.com On 6/27/06, Steve W. <racer99@hotmail.com> wrote:> 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? ;-) > > --> Steve > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >