On 9/23/05, SEan Wolfe <nospam / nowhere.com> wrote:
> snacktime wrote:
> > On 9/23/05, SEan Wolfe <nospam / nowhere.com> 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.