On Fri, Aug 12, 2011 at 10:10 AM, Shane Curcuru <[email protected]> wrote: > (To provide a little context while Gav may be asleep) > > On 8/12/2011 9:26 AM, Rob Weir wrote: >> >> On Fri, Aug 12, 2011 at 3:41 AM, Gavin McDonald<[email protected]> >> wrote: > >>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<[email protected]> > > ...snip snip snip... > >>>> Just a thought: Could you do the entire website in MediaWiki, with only >>>> exception cases (download page, etc.) done in HTML? >>> >>> Just to put a blocker on this right away, we will not be using the wiki >>> as the >>> main website or the main entrance into the OOo world. >>> >> >> Since it is not self-evident to me why a wiki would be a problem for >> the main website, could you explain this a little further? Is there a >> technical problem? Remember, the wiki already comprises several >> thousand pages of website content, so in a very real sense the "main" >> website is already the wiki. > > Performance. As I understand it, the bulk of all apache.org content is > served statically as html files. Putting a major project's homepage website > like the future office.a.o (or whatever name) up as a wiki would add a > significant amount of load to our servers, even for a highly efficient wiki > engine. >
Thanks, that gives some context. So "main" in this case is not necessarily only the top level page, i.e., an eventually openoffice.apache.org or the current www.openoffice.org. Certainly those pages would be some of the most highly-trafficked pages. But we probably have some others that are also, FAQ's, Release notes, download page, etc. But that still leaves the long tail of the thousands of other pages that are individually accessed rarely, but may add up to significant load. I'm surprised there is no caching mechanism for MediaWiki to simply write out up static versions of pages and then invalidate the cache for a particular page when it is changed. In theory you could have the rarely-changed pages be just as efficient as static HTML. Plugins exist that do this for WordPress, for example. > The beauty of the CMS is that while it's easy to work on the pages (either > via SVN or browser), the final result is simply checked into SVN and then > the resulting .html file is just stuck on the production webserver site. > Some projects use a wiki to manage their homepages (i.e. project.a.o, > separate from any community wiki they may have), but the physical homepage > that end-users see is typically static html that's been exported from their > wiki site. > > Gav or infra folk can provide more details, but you should plan on adhering > to whatever performance restrictions the infra team requires for the main > website. > > - Shane >
