[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wikitech-l
Subject:    [Wikitech-l] Re: Summary: Technical strategy for Wikipedia
From:       Gabriel Wicke <groups () gabrielwicke ! de>
Date:       2003-12-30 18:13:23
Message-ID: pan.2003.12.30.18.13.21.198052 () gabrielwicke ! de
[Download RAW message or body]

On Tue, 30 Dec 2003 17:20:21 +0100, Agon S. Buchholz wrote:

> Hi,
> 
> there are several scenarios for the further development of the Wikimedia 
> projects floating around, I'll try to summarize them. Please correct me, 
> if I got things wrong or forgot something.
> 
> There are several problems we are facing currently; most of them are 
> related to the reliability and availability of the Wikimedia services; 
> fúrther issues deal with the scalability of the Wikimedia projects, 
> keeping the exponential growth in mind; there wre several approaches 
> discussed how to solve them, in different levels of depth. Security 
> issues are currently not debated.
> 
> (a) Some Failover - Adding redundancy locally at Verizon, enhancing 
> availability at least a bit.

> (b) High Availability (HA) - Eliminating the Single Point of Failure (SPOF).

I think this can be merged into one point as it only differs in the degree
of redundancy. Live database replication is the hardest bit, even locally,
but having multiple webservers, caches and load balancers is not that hard.

> Clustering wasn't discussed thoroughly, most probably since nobody here 
> seems to have enough experience with this. Also, Clustering with lots of 
> old/slow machines would exponetially increase the amount of 
> administrative time to keep it running. It's also not a good idea for a 
> remote setup with no direct access to the hardware.

Clustering is the only way to get any sort of failover- so this will
always be part of a) and b).

> (f) Caching - Using a proxy like Squid or a Squid hierarchy to enhance 
> accessibility; does neither offer failover not HA; 

Squid supports it out of the box. Squid checks by itself which of its
peers (parents) is up and sends the requests to the working ones if one
goes down. There should be at least two root squids for failover of
course. These are configured as siblings and query each other for fresh
content.

Either a good DNS load balancer or a redirector can be configured to check
for the availability of individual second tier squids and only consider
the working ones. And/ or the second tier nodes could get a load balancer
and two machines to make them more reliable. The squid layer can have HA
if you add enough machines ;-)

> does IMO not allow 
> editing, 

Well, you simply don't cache logged-in pages. I'm using this myself every
day. If your cookie says you're logged in squid does what you tell it with
the Vary header and sends you an uncached page straight from wikipedia.org.

>just speeds up delivering cached (static) pages, if we can 
> build an appropriate Squid hierarchy.

True, but this would do the main job. Latency from de to wikipedia is
currently around 150ms (0.15s) from a standard German colo, that's not
what makes it slow. The problem is an overloaded main server that takes 8+
seconds to reply whenever there's a failure.

> Developing a
> caching scheme would also take some coding time and possibly require
> modifications in the MediaWiki scripts. I would recommend to test such a
> setup thoroughly before going live.

The main modification would be a two-liner that sends out the cache
headers Cache-Control and Vary.
Purging is desirable (then you can have really long timeouts without
ever getting stale content for anonymous browsing) and easy to hook in,
but it's not necessary for the start.

The DNS Magic thing would be nice to have (no separate domains/ redirects
as in all other solutions), but it's not necessary if it turns out to be
too hard to do.

Gabriel Wicke

_______________________________________________
Wikitech-l mailing list
Wikitech-l@Wikipedia.org
http://wikipedia.mormo.org/mailman/listinfo/wikitech-l
[prev in list] [next in list] [prev in thread] [next in thread]