Richards,Michael wrote:
I don't know the exact impact combining them back will have to response times.
Nobody does until it has been tested with realistic amounts of traffic. And since we don't have a staging site with a traffic simulator, it will have to be tested on the real thing. But what if it turns out to be really bad? Will there be a switch that can be easily flipped to restore the old system? The conversion back and forth doesn't seem trivial to me.
My old prejudice about databases say that the bandwidth (bytes/sec) of the database socket is a common bottleneck, which makes it a bad idea to pump blob data through there. Blob-like data can be stored on file instead, with only a filename in the database. I have no idea if this design decision has had any impact on Wikipedia's performance, and I realize it would be just as hard to test as the proposed merger between cur and old.
According to the Webalizer tables, on November 20th, 13 GB was flowing out of the English Wikipedia server, for an average of 158 KB/second (1.2 Mbit/s) (over 24 hours). But do we have any idea what the peak bandwidth is? I guess the amount of traffic between Apache/PHP engine and the MySQL database should be at the same order of magnitude, if every page view reads the text from the cur table.