Scaling

Background

At the time ndla forked from  Dopler the Drupal installation consisted of almost 200 enabled modules. This did not scale very well and a first attempt to create a well scaling architecture was done. When ndla version 1.x were released to school start autumn 2009, it run on several web servers connecting to one common  MySQL database, and served to the public by a load balancing  Varnish web cache. After some tuning this solution could handle the 5-7k unique daily users (most of these during school hours), but not much more. As of school start in 2010 the load was expected to at least double, so a new approach was implemented to make things scale better.

Current Architecture

The main purpose of the new architecture was to be able to scale out instead of scale up. This means that you scale the solution by having a number of identical, self sustained servers, all looking the same. Whenever a performance bottleneck is reached, new servers can be added with almost no performance penalty (near linear scaling).

Creating a scale out solution for this project meant splitting up content production and content serving into to separate drupal instances. The content serving part is served by a read-only installation of Drupal, which is replicated into several identical servers, and the load is balanced between these with a web cache in front.

The two Drupal instances are almost equal.

Publishing content

With a separate

• production on red.
• sync to cm
• sync to slaves
• several hosts may sync
• based on content distribution
• Custom publishing which overrides Drupals internal