My Opera News

For the most part, the setup is the same. We are using Apache 2 in front, and dividing page generation load to 9 mod_perl2 enabled Apache 2 backends. We assumed that 6 backends would work fine, however the sites acted very unstable so we added another 3 with options for even more.

The major changes was as previously noted done within the MySQL database backend. We decided to forego our poorly designed vertically scaled system and replace our entire cluster of 8 or 9 replicating servers with a single more powerful server and some auxilliary replication servers. We keep those for tasks not suitable for execution on the main server where speed and efficiency is a necessity.

As of now, I'm very happy with the performance of our new database server. It is gnawing its way through between 2,000 and 5,000 SQL queries per second. And we're not talking ultra lightweight queires here. Considering this room for improvement with regards to optimising our application's queries and architecture, there's a bit of leeway with regards to how the current setup will scale to more users.

I'm not going to claim that the site is very much faster than it used to be, although it seems a bit speedier to me. However, the most important usability improvement we gained this time around was that we got rid of the asynchronous replication setup. Meaning, that when you post a blog post, you should see it immediately. When you delete a post, it will be gone immediately. And when you sign up, the site won't claim you aren't a member. The monkeys might even play a bit nicer.

Anyhow, the Opera Community and related sites are now served by a heap of machinery containing some 50 CPUs of decent power (most of them 2.8GHz Intel Xeon) and some 60GB or more of RAM. Oh, and there are some terabytes of storage laying around.