ELMSLN optimization: Cost and Scale

I did a post the other day about ELMSLN Performance Optimization all about lessons learned and looking at some popular techniques and applying them. These are techniques that can be applied to ANY Drupal (and in many cases non Drupal) application to increase performance. This article looks at the real world price of performance tuning.

Context

Its one week into the semester. Most announcement emails have gone out over the weekend or just prior to it (6 days ago) so we're starting to get the "real world" traffic of students flooding in for the semester. Our unit supports around 40 courses in total. This semester, we are at about the midway point between our transition from our Legacy "elearning" system that was built on Drupal 6 and our production OnlineAA Drupal 7 / ELMSLN instance.

For reference, all of our traffic is authenticated with an extremely minimal amount of anonymous traffic on the few parts of the system that are front facing.

ELMSLN is infinitely more complex then our old setup and infinitely better optimized / planned (hey I'm much better then I was 6 years ago when we built that). Here's our two systems by the numbers and visually

Legacy

11 Courses running this semester

18 Sections of students

~730 students

2 servers. 1 for apache, 1 for mysql

$1,506 / year

System 1 (Apache)

e-Learning Apache Server

System 2 (database)

Notice the spikes on this machine especially! This is even with two systems dedicated to usage

Optimized ELMSLN instance

14 Courses running this semester

28 Sections of students

2,380 students

1 server

$903.00 / year

Conclusions

We were able to go from 2 servers to power our portfolio which prior to migration actually had higher specs then today, to our new environment which has less servers, more capability, and yet is able to handle more resources more cheaply. Over the next year we'll continue slowly transitioning our portfolio off of our legacy instance and onto our super happy ELMSLN production instance. If we need to scale this box up resource wise, we can. If we need to split out to multiple servers / setups, we can. But we know that we're using our current resources far more efficiently then we once did.

Production gains by the numbers

  • 3 more courses
  • 10 more sections
  • 302% more students
  • $603 less per year

This not only translates to less cost, it's lead to a better student / user UX as far as performance goes.  Past metrics have shown that our average page loads in the past have been in the .3 to .6 seconds range! All this before we scale out, go into crazy additional load balancing, more servers / dedicated DB server, auth cache, mod SPDY or Varnish / Pound techniques.