On 22 January, WMF staff and contractors switched incoming, non-cached requests (including edits) to the Foundation's newer data centre in Ashburn, Virginia, making it responsible for handling almost all regular traffic. For the first time since 2004, virtually no traffic will be handled by the WMF's other facility in Tampa, Florida.
"Located in the Washington, D.C. metropolitan area, Ashburn offers faster and more reliable connectivity than Tampa, and usually fewer hurricanes", wrote Guillaume Paumier, the Foundation's Technical Communications Manager in a comprehensive blog post published before the switchover.
As of time of writing, the migration has been declared a success, with the two "backup" maintenance windows previously scheduled for later this week scrapped. Total editing downtime so far has been estimated at 30 minutes, with other smaller problems extending further. Overall, however, the migration seems to have been characterised by its praise-worthily minimal impact.
The data centre in Tampa will continue to be maintained as a "hot failover", with "servers ... in standby mode[, ready] to take over, should the primary site experience an outage. Server configuration and data will be synchronized between the two locations to ensure a transition as smooth as possible in case of technical difficulties in Ashburn", writes Paumier. Additionally, the Signpost understands that the Tampa data centre will continue to be used for image scaling in the short term, before that too is migrated to Ashburn. Across the two data centres, the Wikimedia Foundation currently operates a total of approximately 885 servers, serving around 20 billion page views a month.
On 19 December, WMF Deputy Director Erik Möller committed the Foundation to holding quarterly reviews of all its major engineering projects, including the Visual Editor, Mobile, Echo and Flow projects. First up, however, was the Editor Engagement Experiments (E3) team, who held their review last week. That meeting included both the E3 team itself, as well as senior managers at the Foundation (Executive Director Sue Gardner, Director of Features Engineering Terry Chay, and Erik himself), with the draft transcript giving an interesting insight into a world that can often appear to community members as inherently homogeneous.
The report phase of the meeting makes for mixed reading. Although all of the E3 team's projects – post-edit feedback, improving the account creation process, "Onboarding" (giving new users more information on possible editing tasks), and a campaign targeted at donors – appeared in some sense successful, none has yet been able to make a sizeable dent into the English Wikipedia's editor decline. Onboarding showed the most promise, with an unconfirmed 30% increase in users making an edit to mainspace within 24 hours of registering (21.7% vs. 16.5%); a newer project, looking at the provision of "guided tours" (walkthroughs) of the site, was also discussed. The analysis phase focussed on the balance between foundational and user-facing work, the lack of integration between the E3 and E2 teams (i.e. Echo and Flow), and the extent to which gains in terms of "1+ edit" users translated into increases in the numbering of returning editors. There was also disagreement about whether the E3 team was focussed tightly enough on the active editors brief.
The Visual Editor and Mobile projects (including mobile editing and Wikipedia Zero subprojects) are both scheduled to be reviewed in February, although the exact format of the review may be tweaked between then and now.
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.
Discuss this story
On First Quarterly Review makes for interesting reading, just wanted to chime in with two points...
Anyway, thanks for the coverage Jarry! Steven Walling (WMF) • talk 22:30, 23 January 2013 (UTC)[reply]
The data centre migration seems to coincide with a delay I've been seeing in article cache invalidation. Prior to 22 January, edits I submitted were immediately reflected as the latest version of the article, assuming the page wasn't subject to pending change review (ah, the ever-increasing indignities of editing without logging in). In other words, after supplying an edit summary and submitting a change, the article page would automatically refresh, perhaps with a brief delay, with the changes visible. This isn't necessarily true anymore. In the past, even when the site was under a heavy load for one reason or another, a subsequent null edit would let me see the version of the article that reflected my changes; that isn't necessarily true anymore. Another change I never saw until now: it is possible for a null edit/purge to fail even when article history shows my changes. In other words, it now appears possible for the most recent WP:permalink for an article to differ from the default version of an article. Assuming I had just edited Metacarcinus these can now differ, something I haven't seen before, after years of editing:
68.165.77.6 (talk) 04:23, 25 January 2013 (UTC)[reply]