Initial Results Running DNN Redis on Awesome.Net

At Applied Innovations we’ve been huge advocates of the DNN platform and over the past fours years we’ve been actively involved with Windows Azure Pack (WAP) because we believe this is the future of shared hosting.  So when we launched our WAP environment into production earlier this year as awesome.net, DNN was something we wanted to see running on that platform.  Unfortunately, without a caching provider getting DNN to run in a load balanced environment like Awesome.net you have to rely on the file based caching provider and in a multi-tenant / shared environment this becomes impractical. So a few days ago when David Rodriguez released his redis caching provider for DNN I was ecstatic!!

So what better time to experiment with it than that lull between the holidays.  Earlier today I deployed a simple entry level VM in our cloud environment (This particular VM has 2 CPU, 2GB memory and 50GB of disk and we typically sell these for $49.95/month), I downloaded the redis for windows binaries from MS Open Tech, opened port 6379 in windows firewall and before you knew it I had a working redis server running on windows:

image

Next I created a new DNN site from the application gallery in the awesome.net portal (which is built on top of Windows Azure Pack) and followed David’s instructions for how to install the redis caching provider.

Installing the redis caching provider

  1. I installed an out of the box DNN site running 7.3.
  2. I downloaded the release binary as part of the github distribution found at: https://github.com/davidjrh/dnn.rediscachingprovider
  3. I installed the extension into my DNN site using the extension install wizard.
  4. I downloaded the web.config and made the following two changes:
  1. I edited the RedisCachingProvider connection string to the following: 
    1. <add name=”RedisCachingProvider”
      connectionString=”XXX.XXX.XXX.XXX,ssl=False”
      providerName=”DotNetNuke.Providers.RedisCachingProvider” />

      Where
      XXX.XXX.XXX.XXX is the IP address of my redis server.

  2. I edited the caching provider definition to the following:

  3. <add name=”RedisCachingProvider” type=”DotNetNuke.Providers.RedisCachingProvider.RedisCachingProvider, DotNetNuke.Providers.RedisCachingProvider” providerPath=”~ProvidersCachingProvidersRedisCachingProvider” useCompression=”false” silentMode=”true” keyPrefix=”DNNRedis” host=”XXX.XXX.XXX.XXX”/>

    Again where XXX.XXX.XXX.XXX is the ip address of my redis server. I also added a unique keyprefix because I was running more than one DNN site at the same redis server instanct.

    That’s it. That’s all I did enable the redis caching provider for my site.

    Load Testing My Redis powered webfarm.

    Now that I had redis setup and my caching provider enabled it was time to throw traffic at the site. I decided to use Loader.IO for this and started running concurrent sessions against the site starting at 10 and ramping up to 5000 concurrent users over a 3 minute period. to see how many users I could sustain and still see a 2-3 second page load time. 

    NOTE: This is with ZERO customizations or enhancements, this is strictly an out of the box install of DNN community edition in a WAP powered web farm.

    With one Web Worker

    With the site set to a single web worker I was able to get to about 110 concurrent users with 2.5 second of page load time and manually surfing the site while the test was running with 110 users I was able to confirm the site was in fact usable.

    With two Web Workers

    Ramping from 1 web worker to 2 web workers with nothing other than moving the slider from 1 web worker to 2 web workers I was able to get to about 350 concurrent users with about a 2 second page load time.

    With four Web Workers

    Moving from 2 web workers directly to 4 web workers, again simply moving the slider, I went from 350 concurrent users and a 2 second page load time to 900+ concurrent users and a 3 second page load time. 

    image

    This before applying any sort of DNN performance improvements or best practices, it’s literally an out of the box install.  Oh and as for load on the redis server it was using about 1% cpu and negligible memory.

    Overall Impressions

    I think the redis caching provider David has released was a long time coming.  Today’s websites are moving away from traditional shared hosting services and moving towards elastic shared cloud hosting and this type of caching providers makes that migration effortless.  This is a version 1.0.0 product so I’m sure we’ll see improvements over time but after spending all of 30 minutes setting up redis and a DNN server in a $99/month multi-tenant shared cloud hosting environment to be able to sustain nearly 1000 concurrent users with reasonable performance is pretty amazing!

      Leave a Reply