In the recent past, there have been numerous posts relating to the number of requests per second and performance of Rails, etc. I had this idea and was wondering what you guys think.. I''m looking at an application where there are a number of distinct sites that need to access the web application (8 ~ 10 branch offices). Is it a good idea to have a central database somewhere and deploy a web server and the identical Rails app to each of the branch offices? That way, the people access the Rails app running on their relatively local web server. The Rails app accesses the central database for all the data so that the consistency is maintained. Does this sound like something that could work? Are there any obvious issues? I know the biggest issue is that updates have to be propagated to each of the sites, but other than that, what do you think? Cheers Mohit.
> In the recent past, there have been numerous posts relating to the number of > requests per second and performance of Rails, etc. I had this idea and was > wondering what you guys think.. > > I''m looking at an application where there are a number of distinct sites that > need to access the web application (8 ~ 10 branch offices). Is it a good > idea to have a central database somewhere and deploy a web server and the > identical Rails app to each of the branch offices? That way, the people > access the Rails app running on their relatively local web server. The Rails > app accesses the central database for all the data so that the consistency is > maintained. > > Does this sound like something that could work? Are there any obvious > issues? > I know the biggest issue is that updates have to be propagated to each of the > sites, but other than that, what do you think? > Cheers > Mohit.If you''re database is centralized why not keep the web server centralized and simply buy a box that is 8 ~ 10 times as powerful as the boxes you''d buy for each office? Seems like a much bigger headache having a webserver at each office and you don''t gain anything since if their Internet connection goes down their app won''t work cause the database is still remote... ? -philip
i dont even think the central server has to be 8-10 times as fast as a local one would be. just think of the speed increase when the database is local, e.g. install phpmyadmin at your home pc and access a mysql server on a remote site... thats damn slow! i think in most cases its better to have db and web on one site with a good connection inbetween and if thats still too small, throw hardware at _one_ site instead of throwing it at all the branch offices. just imagine you''d have to get one technician to each office to install the hardware, usually you pay for every mile the drive, so they didnt do anything and cost huge amounts of money... 2006/8/11, Philip Hallstrom <rails@philip.pjkh.com>:> > > In the recent past, there have been numerous posts relating to the > number of > > requests per second and performance of Rails, etc. I had this idea and > was > > wondering what you guys think.. > > > > I''m looking at an application where there are a number of distinct sites > that > > need to access the web application (8 ~ 10 branch offices). Is it a > good > > idea to have a central database somewhere and deploy a web server and > the > > identical Rails app to each of the branch offices? That way, the people > > access the Rails app running on their relatively local web server. The > Rails > > app accesses the central database for all the data so that the > consistency is > > maintained. > > > > Does this sound like something that could work? Are there any obvious > > issues? > > I know the biggest issue is that updates have to be propagated to each > of the > > sites, but other than that, what do you think? > > Cheers > > Mohit. > > If you''re database is centralized why not keep the web server centralized > and simply buy a box that is 8 ~ 10 times as powerful as the boxes you''d > buy for each office? > > Seems like a much bigger headache having a webserver at each office and > you don''t gain anything since if their Internet connection goes down their > app won''t work cause the database is still remote... > > ? > > -philip > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Michael Siebert <info@siebert-wd.de> www.stellar-legends.de - Weltraum-Browsergame im Alpha-Stadium -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060811/5a697dd5/attachment.html
Philip Hallstrom wrote:>> In the recent past, there have been numerous posts relating to the >> number of requests per second and performance of Rails, etc. I had >> this idea and was wondering what you guys think.. >> >> I''m looking at an application where there are a number of distinct >> sites that need to access the web application (8 ~ 10 branch >> offices). Is it a good idea to have a central database somewhere and >> deploy a web server and the identical Rails app to each of the branch >> offices? That way, the people access the Rails app running on their >> relatively local web server. The Rails app accesses the central >> database for all the data so that the consistency is maintained. >> >> Does this sound like something that could work? Are there any >> obvious issues? >> I know the biggest issue is that updates have to be propagated to >> each of the sites, but other than that, what do you think? >> Cheers >> Mohit. > > If you''re database is centralized why not keep the web server > centralized and simply buy a box that is 8 ~ 10 times as powerful as > the boxes you''d buy for each office? > > Seems like a much bigger headache having a webserver at each office > and you don''t gain anything since if their Internet connection goes > down their app won''t work cause the database is still remote... > > ? > > -philip >Hi Philip, Thanks for the reply. The benefits are a few fold (in my opinion): 1. Locally deployed servers will be faster (except the query part, of course) 2. The load on the local servers will be less thereby allowing more processing the scripts, etc. 3. The deployment can be phased out as and when the budget allows a site to come online Of course, it''s a real pain to update the applications.... Anyway, it''s just an idea that I''m playing with... I guess my main question was about whether there are any technical limitations to this approach. One benefit (application?) of this approach is also to web hosts (like mine) who don''t support RoR yet. I can use the database over at their site and deploy my Rails application to the few computers that need access to the data. Of course, I lose out on some of the benefits of using the web :D Cheers mohit.