seth vidal wrote: > 1. get the websites and docs people to split out a structure in the wiki > that is the final release lay out. This will be frozen N days prior to > release and static pages will be generated. This static content will be > fedoraproject.org/ I definitely think this is a good idea. We need to be able to make the most hit pages on day of release static pages. That should help reduce load a fair amount, which we already saw a bit of my the static pages put in place this afternoon. I wouldn't think this to be a major issue, though we will want to be sure to let the websites and docs teams know well in advance what we would like to see. > 2. the static content will get mirrored to a new set of mirrors in the > world that we will recruit people into. These will be simple http-only > mirrors. Mirrored is good. I am more inclined to use resources we have control of to prevent undo management complexity. Bandwidth didn't seem to as much of an issue as server load. I am thinking we should use Duke, PHX and ask Stacy nicely for a bit of space at the TPA DC. This helps disperse the load across several locations. We would still need to have the server hardware to back it up with of course. The PHX DC has a few servers to throw at the problem. 4 Proxy servers and 2 app servers. The Xen boxes could always be added to that mix on release week (guests shut down and Apache running on the host boxes) to assist with the increased load. > 3. fedoraproject.org can be globally load balanced using (more or less) > dns round robin (more robust mechanisms are welcome) > > 4. we make the wiki server multiple and redundant by making use of > multiple machines. I'm in agreement here as well. --Jeffrey
