Back in 2006 there’s been an interesting presentation about the underlying design principles of Second Life. It’s being hosted at the company website of MySQL.
The presentation goes about 45 pages. The most interesting page is for sure 25, because it gives a big overall picture about the underlying architecture of SL.
So, here without further fanfare, is this picture:
As you can see, there are quite many parts behind Second Life that we are normally not really aware of. The only part we can already build ourselfs is the viewer. This is now available as the real deal under the GPLv2 already.
But the rest – well… the most important part is the simulator. That’s the machine that’s computing the avatar movement and so on.
When it reboots it’s got to take it’s data from the central database. Once this is done, it should be more or less in an operational state. States and assets of the sim are being saved on an extra machine, the assets server. That’s just a big, clustered filesystem, so there’s not much intelligence on this machine at all. I guess it’s being used to save data in it which needs to become fast available, and of course there’s nothing faster then getting data of a filesystem instead of a database. A database adds for the same task many new layers the request must go through, so that’s quite a good way to speedup things for trivial tasks.
Well, the rest though is in databases, running under MySQL. The "Central" DB, the logging db and a database farm (for things like inventory and so on, I guess). But the simulator does not talk directly with those three databases normally; it talks to them through the dataserver. So, what’s the job of the dataserver? It is to cache requests and take load away from the databases and to deliver the content to the sim.
So, when we download textures, shapes and such, the sim first talks to the dataserver and if it is already cached, the server directly replies instead of asking the database.
The dataserver, though, is one of the bottlenecks of this architecture. Second Life uses at the moment a kind of homebrew protocol for the communication between the dataserver and the sim – this means also between the sim and the viewer. The result is, while it has done its job pretty well in earlier times, it does not scale really well, as it seems.
Scaling could be done, perhaps, but why take the effort in creating an own scaling solution, when you can change the protocol from homebrew-inhouse into a wellknown standard like HTTP, where good, proven and reliable scaling solutions exist already for a long time? So that’s the main reason why LL wants to get rid of this old, homemade protocol, and replace it with HTTP. The sim should be able to talk with the dataserver (in the presentation it’s replaced with a webserver) via HTTP, because it scales much better and more easily.
Ah, yes, and Wilkes gave us also one motto of LL in the presentation: databases are not special. So why optimize them, when you can scale more easily? Well, we’re going to see the impact of the new messaging system real soon since LL is putting a testgrid for it up right now. I hope it’s one step into the right direction to make SL a better experience for all of us.
Bartholomew Gallacher