6 ms·

> Oh don't get me wrong, I'm not saying I would host a site like Wikipedia on a single server, I'm saying that it's more than possible. This is incorrect. Many

> Oh don't get me wrong, I'm not saying I would host a site like Wikipedia on a single server, I'm saying that it's more than possible. This is incorrect. Many of the numbers you throw out ignore that in order to serve its content a server must do some work, which requires both CPU time and memory. Assuming you were able to eliminate hard drives and fit everything into RAM, you still have the problem that to serve requests and do that work you need RAM. >That server can have something like 4 TB of memory in it. The entire Wikipedia database is just 5.6 TB uncompressed. >Yes, you really can fit most of Wikipedia in memory! This is incorrect. According to Wikimedia[2], the entire uncompressed size of Wikipedia is 19TB as of 2019, and the site has grown since. Talking specifically about hard drives: > Spindles!? Are you kidding me? There are gaming PCs being built right now with 2 TB NVMe drives in them that can individually put out 7 GB/s and 1M IOPS! Who the hell puts servers on spinning rust in this day and age? That lone, single NVMe drive is putting out 56 Gbps by itself. Throw in a smidge of caching, and it could saturate those aforementioned 2x200 Gbps ports. Firstly, gaming PCs are almost always ahead of the curve when it comes to performance on everything. Secondly, to your question about who puts servers on spinning rust -- Pretty much everyone. Backblaze even releases HDD reliability ratings[1] based on what they observe in terms of the spinning platter drives. Also, your 2TB NVMe drive is going to cap out at around a quarter of what the large-spindle raid controller can, and you can have a few of those in each system if you want. Sure, a PCIe 4.0 NVMe drive is going to get you 7.88GB/s in your motherboard slot but a PCIe 4.0 raid controller can have four times that bandwidth available to it. But for argument's sake let's say you decided to swap out your raid controller for a PCIe 4.0 card that does NVMe and has onboard raid (these don't exist for purchase yet that I can find at my usual suppliers but I imagine they're coming). Now you have a size problem. The largest current best available SSDs are Sabrent's 8TB PCIe 3.0 drives. This will cut the performance considerably but is probably the sweet spot for size & speed. You need 4 of them just to host current Wikipedia, limiting any growth, and certainly without factoring in any other parts of the system that may take away from the operation. For comparison's sake to the 2TB NVMe drive in your example, my old homelab can hit 5 GB/s on five spindles that I bought in ~ 2011-12 and they're all old and cheap, not enterprise-grade gear. > So no, I would not put the entirety of Wikipedia on just one server, that would be silly. > I would put it on two. > Okay, maybe three, for redundancy. Just in case. Then you have issues of bandwidth by having so few connections, as well as the poor user experience of trying to visit a site that exists and is served in only three places (hopefully around the globe). It's also bad for reliability because if any one site loses its connection suddenly your 200GB/s traffic is pushed onto the other servers. If you want a sense for how reliability engineering works you should look at how Netflix does testing and why they've managed to withstand regional AWS outages despite being hosted on AWS[3]. Wikimedia lays out their system set up pretty well on their own page[4]. Could you technically host wikipedia on your own systems? Sure, lots of people do, go visit Reddit's r/datahoarders and I'm sure you can find more than a few who have their own local copies. Could you actually replace production wikipedia on the Internet with the setup you describe? No, you cannot. I also suspect you haven't costed out the server setup you describe, as it seems incongruous to say that they spend too much while advocating replacing their entire server stack with cutting edge hardware (and will they need to do so annually in order to keep up?). [1]: https://www.backblaze.com/blog/backblaze-hard-drive-stats-for-2020/ https://www.backblaze.com/blog/backblaze-hard-drive-stats-fo... [2]: https://meta.wikimedia.org/wiki/Data_dumps/Dumps_sizes_and_growth https://meta.wikimedia.org/wiki/Data_dumps/Dumps_sizes_and_g... [3]: https://netflixtechblog.com/lessons-netflix-learned-from-the-aws-outage-deefe5fd0c04?gi=d2cab0be29ff https://netflixtechblog.com/lessons-netflix-learned-from-the... [4]: https://meta.wikimedia.org/wiki/Wikimedia_servers https://meta.wikimedia.org/wiki/Wikimedia_servers

jiggawatts 5y ago
Obviously I'm not being serious about hosting Wikipedia on just 3 servers. That would be a nightmare for maintenance and availability management. My point is that you could physically host their content on just one server, and nothing you have said counters that. Who cares if Blackblaze -- a backup company -- uses hard drives? Of course they do! They're not hosting Wikipedia though. My point was by using current-generation COTS hardware, it is entirely possible to host a huge website on a single box. It is. It really is. This is not about what other people generally do. This is about what is possible! You keep getting bogged down by the practicalities of real-world site management. For the sake of argument, if I were to engineer a serious solution for this problem, I would be looking at hardware more like what Cloudflare uses for their edge cache boxes. They did the legwork to find the sweet spot for price/performance. This is typically a single-socket server with a 48-core AMD EPYC processor and 100 Gbps Ethernet. This CPU model is much cheaper than the 64-core flagship, but has the same amount of cache. (They're made from the same 8-core chiplets, but with 2 cores fused of due to defects.) In these servers I would use PCI-e quad port NVMe adapters, as you said. The capacity requirements aren't as high as you think either, because the content can be sharded. The 5.6 TB number is for english Wikipedia, not all of Wikipedia + Wikimedia as a whole! So those 4x 8 TB cards are more than sufficient. Heck, even 4x 2 TB is enough for a while. The trick here is to apply some sort of lightweight compression on the text. That 5.6 TB compresses down to just 100 GB! In practice, you could easily get better than 3:1 ratios even with a very fast compressor set to "light" compression. Then I would distribute these servers around the globe, with about 3 per location. One for english, with the other two for all the other languages. Each server would have a local, read-only replica of the language-specific databases with asynchronous streaming from the master copy. I'd distribute this to about 5 regional locations, and nominate one server per language as the "write master" where updates occur. So for each language you'd have 1x read/write and 4x read-only. These would be at different locations, so for example German wikipedia would have the read/write replica in Germany. English would be at some US east-coast location. Etc... Then you'd need some boxes for nonproduction test, dev, etc... All of the remote edge servers would be load balanced using a DNS-based method, with no local load balancers. The servers' 100 Gbps ports would be directly connected to the peering routers, the same way Cloudflare and the like does it. This would add up to 1.5 TBps of traffic that you really could physically serve (5 x 3 x 100 Gbps). Overall, the entire platform could be handled by something like 20-25 servers. That's it. Now, I tell a small lie: Wikipedia hosts only the text! WikiMedia has the pictures, which don't compress well and requie much more disk space. This is best served with technology similar to AWS S3, which can be replicated with open source software and some boxes packed with hard drives. But again, you're probably overestimating the capacity required, and underestimating how much you can pack into a server these days. Just to reiterate: the above is predicated upon having an efficient codebase, and Wikipedia isn't currently efficient enough to make this possible. It would take a rewrite of the code to achieve this, and that would cost more than their current hardware, so it doesn't make financial sense. Most web sites are in a similar situation, which is perhaps why your perspective is skewed: Your expectations of software performance capability might be off by a few orders of magnitude!

jiggawatts 5y ago

Obviously I'm not being serious about hosting Wikipedia on just 3 servers. That would be a nightmare for maintenance and availability management. My point is that you could physically host their content on just one server, and nothing you have said counters that. Who cares if Blackblaze -- a backup company -- uses hard drives? Of course they do! They're not hosting Wikipedia though. My point was by using current-generation COTS hardware, it is entirely possible to host a huge website on a single box. It is. It really is. This is not about what other people generally do. This is about what is possible! You keep getting bogged down by the practicalities of real-world site management. For the sake of argument, if I were to engineer a serious solution for this problem, I would be looking at hardware more like what Cloudflare uses for their edge cache boxes. They did the legwork to find the sweet spot for price/performance. This is typically a single-socket server with a 48-core AMD EPYC processor and 100 Gbps Ethernet. This CPU model is much cheaper than the 64-core flagship, but has the same amount of cache. (They're made from the same 8-core chiplets, but with 2 cores fused of due to defects.) In these servers I would use PCI-e quad port NVMe adapters, as you said. The capacity requirements aren't as high as you think either, because the content can be sharded. The 5.6 TB number is for english Wikipedia, not all of Wikipedia + Wikimedia as a whole! So those 4x 8 TB cards are more than sufficient. Heck, even 4x 2 TB is enough for a while. The trick here is to apply some sort of lightweight compression on the text. That 5.6 TB compresses down to just 100 GB! In practice, you could easily get better than 3:1 ratios even with a very fast compressor set to "light" compression. Then I would distribute these servers around the globe, with about 3 per location. One for english, with the other two for all the other languages. Each server would have a local, read-only replica of the language-specific databases with asynchronous streaming from the master copy. I'd distribute this to about 5 regional locations, and nominate one server per language as the "write master" where updates occur. So for each language you'd have 1x read/write and 4x read-only. These would be at different locations, so for example German wikipedia would have the read/write replica in Germany. English would be at some US east-coast location. Etc... Then you'd need some boxes for nonproduction test, dev, etc... All of the remote edge servers would be load balanced using a DNS-based method, with no local load balancers. The servers' 100 Gbps ports would be directly connected to the peering routers, the same way Cloudflare and the like does it. This would add up to 1.5 TBps of traffic that you really could physically serve (5 x 3 x 100 Gbps). Overall, the entire platform could be handled by something like 20-25 servers. That's it. Now, I tell a small lie: Wikipedia hosts only the text! WikiMedia has the pictures, which don't compress well and requie much more disk space. This is best served with technology similar to AWS S3, which can be replicated with open source software and some boxes packed with hard drives. But again, you're probably overestimating the capacity required, and underestimating how much you can pack into a server these days. Just to reiterate: the above is predicated upon having an efficient codebase, and Wikipedia isn't currently efficient enough to make this possible. It would take a rewrite of the code to achieve this, and that would cost more than their current hardware, so it doesn't make financial sense. Most web sites are in a similar situation, which is perhaps why your perspective is skewed: Your expectations of software performance capability might be off by a few orders of magnitude!