From: Joe Van Dyk Date: 2005-09-24T09:05:20+09:00 Subject: Re: Large scale sites? Anyone? Anyone? On 9/23/05, SEan Wolfe wrote: > snacktime wrote: > > On 9/23/05, SEan Wolfe wrote: > > Do you mean simultaneous users or actually completed requests per second? > > 200 req/sec is over 8 million requests in a 12 hour period. 200 simultaneous > > connections is another story, and shouldn't be a real issue for > > apache/lighttpd and rails. > > Well, basically the site currently serves about 160,000 visits/day, > 8,000,000 pages/day, and 18,000,000 hits/day and pushes out about > 135GB/day. This is all currently being served by apache and static HTML > with a lot of includes. > > Their box is a 4x CPU, linux box, with 1.5GB of RAM. I took some > activity samples, and it seems that their load on the box averages about > 35-40%. MySql is pretty much idle, since currently it's barely used. > > They update about every hour, but if they had some sort of CMS, they > would like to update more frequently, be even more dynamic. > > The idea of keeping things on static pages seems fine. I just don't know > how responsive it would be to frquent updates. Each update changes > different navigation in several locations (always keeping the freshest > content within a click, from any location on the site). > > > The main issues you will have is setting up load balancing and failover. We > > use ServerIrons a lot as front end load balancers. Personally I love them as > > they take a lot less time to manage then most open source solutions and have > > a lower failure rate. Distributing access to your databases will probably be > > one of the main challenges, as well as having some type of failover > > mechanism. For a good general caching system you might take a look at > > memcached. We use it a lot and it's a great tool for taking the load off of > > your database servers. > > Currently, their emphasis is on Cost to Implemenet at the moment. Their > Hosting service currently provides them with one dedicated box, and a > block of bulk bandwith. The provider thinks that a CMS would require a > second box to split the load. This would add additional monthly costs to > their plan. So any dedicated load balancer is up to the location > company, and the cost to implement. It's hard to believe that such a > large site has such a small bugget! :P > > Becasue of cost, they were also looking into off-the-shelf open source > solutions. But most of the ones that I've seen didn't seem to fit well, > or were just a big mess of PHP. > > Also there is the issue with my costs as well, since I don't want to > spend a great deal of time developing the site. Ruby makes a great > choise for this aspect. > > > In our case everything is dynamic so we don't have a use for squid, although > > you could use that in conjunction with a ServerIron, or in place of if you > > just want to throw up several linux boxes with squid and use round robin > > dns. Personally I don't care much for messing with dns techniques unless you > > need to geographically distribute your servers. > > The only DNS trick I guess I was thinking of possibly doing is having > two sites, one for the CMS application where the editors and writers add > their content, and then one site that the visitors see. The CMS site > would then publish content to the live site. The CMS site could be more > heavy on the app side, and not need any serious hardware specs, since it > would only have to serve at most, about 50 users a day. > > > Anyways, this is still in the very early stages yet. I would like to > hear more input! Rails + Caching should be a perfect fit for you. Just expire the caches whenever new content is generated and it should be almost as fast as plain static pages.