On 6/4/05, Mark Williamson <node.ue(a)gmail.com> wrote: You can't make a subnet appear in multiple places without ugly hackery and an extra network connection (tunnels, perhaps address translation, maybe origami routing). So unless you're also renumbering (which has it's own outage causing issues) most places are pretty much stuck. All of this says that while you can avoid downtime it's usually costly and complex, and if there are problems they often cause more downtime then you would have had without the the extra measures.

Mark Williamson wrote: Well, this involves other difficulties and complexities and potentially much more extended downtime. (And potentially, no actual downtime but a period of extreme slowness.) It was a difficult decision as to which to do, but I chose the "fast move all at once option" after a consideration of time and resources and difficulty on the volunteer admins. In this case, all the volunteer admins need to do is be around when we bring things back up. Ideally, nothing should need to be done -- the machines will all be unchanged in configuration, our ip numbers will be routed to the new cage, everything should be identical. Of course, nothing like this is ever ideal, and we should expect catastrophe. --Jimbo

ultrablue(a)gmail.com wrote: Hehehe... :) Here's a preview of the downtime page Kate's been throwing together: http://fuchsia.knams.wikimedia.org/ If you've got additional translations, please e-mail them to me directly or pop in at #wikimedia-tech on irc.freenode.net; the mailing lists will probably be down during the downtime. -- brion vibber (brion @ pobox.com)

ultrablue(a)gmail.com a écrit: Well, your wishes were obeyed. The Paris squids showed to everyone accessing wikipedia, that we again had a crash, were trying to fix it, and would be back soon. It was not a maintenance page which was shown, but a crash page. Not sure it is exactly good for our image. Ant

Hi Mark, I'm assuming your "top 5" is based on article count. I don't think that's right in this context, as it will be the visitors who see the error page - the articles aren't the ones looking at the error page, after all! That would be, in order, English - Japanese - German - Spanish - French. That top 5 would cover 80% of our visitors. (the top 3 would cover 70%, just English covers 40%) Unfortunately (but for this purpose, fortunately), if you look at the graph of cumulative %age of visitors/day by rank in visitors/day, the curve is very very steep. That means that with just a few languages, you can cover almost all visitors. 11 languages will cover 93%. In order: English - Japanese - German - Spanish - French - Polish - Dutch - Swedish - Chinese - Italian - Portuguese. That also says a lot about us: most of these are languages which originate in Western Europe, the only exceptions being Japanese, Chinese, and Polish. 14 languages will cover 95%; just add Hebrew - Danish - Finnish to the end. (again, in that order) You could try to unify the Scandinavian versions of the message (Danish, Swedish, and Norwegian), if you want to I can help with that. 23 languages will cover 97%, add Esperanto - Norwegian - Russian - Arabic - Slovene - Catalan - Malaysian - Korean - Romanian. As you can see, the more languages you add the less quickly it approaches 100%. So it really all depends on what ratio of server load to number of people who can read/understand it in their language you think is best... My personal opinion is that the 11 languages is the best option. It might also be a good idea to have a shorter message for the lower languages in the list. Mark On 07/06/05, ultrablue(a)gmail.com <ultrablue(a)gmail.com> wrote: -- SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM POSSIT MATERIARI ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE

In response to the first part: Yes, it is that much of a performance hog. Just a little bit of text isn't that bad, but when you multiply it times hundreds of thousands of visitors, it gets to be significant. In response to the second part: I would imagine that this sort of thing would take up more bandwidth as well. However I don't know how much bandwidth either would take up - it may not be too much. Mark On 08/06/05, Pavol Cupka <pavol.cupka(a)gmail.com> wrote: -- SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM POSSIT MATERIARI ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE

Mark Williamson wrote: This is so obviously not true. We're talking about a small set of static HTML pages here. For 100 languages, that's 100 pages. Most people will look at no more than 2 of them. Millions of websites have more pages than that, visitors that surf through them more, and run from a single server without a performance problem. Timwi

That's true, I had envisaged the one (rather bulky) HTML page containing all the different languages' error messages, and people could switch the language of the error message by clicking the desired language's name. I didn't think we'd be able to get different error pages for the different language wikis, since every single Wikimedia site gets served the same error message at the moment. But if it's technically possible to do this then it would be much better. We could do a combination of both: have the host language show up as the central/main language on the error page, but also have the top 5/10/... languages hidden in the HTML so the user can switch to that language error message if necessary. Or just English, if people feel that's an adequate secondary error message for non-English language wikis. ~Mark Ryan On 6/9/05, Mark Williamson <node.ue(a)gmail.com> wrote:

Pavol Cupka wrote in gmane.science.linguistics.wikipedia.misc: for something as trivial as the downtime page, which is mostly static content with some translated strings, i don't think it should be a problem. yesterday, we served the downtime page for every wiki from a single server (dual 2.2GHz Opteron) with about 15% CPU load. currently it uses the Accept-Language to decide what language to serve. if that isn't specified, or is "en", it should be possible to use the Host header to decide the language... i'll have a look at implementing that. kate.