The other day we blogged about our website slowing down. And what we did to speed it back up.

We went through a bunch of different optimizing steps, tuning up the site’s performance bit by bit.

Last week we took the next logical step: Moving the PlanetMagpie.com website (and its CMS database) to dedicated Web servers.

Boosting Sitefinity’s Performance, One Stage at a Time

Initially, we tried to speed up the site using:

  • Database tuning
  • Recompiling Sitefinity dependencies in release mode
  • Page and content caching
  • Slimming down webpages
  • Reconfiguring and tuning web server Application Pools
  • Compressing HTML and scripts

Even after all this tuning, we still had some issues. Slow spots, coming from certain pages with too many data calls.

In the Sitefinity application, the more dynamic controls on a page, the slower the page loads. Those pages have to communicate with the CMS database over & over while they’re open (data calls).

Think of it like the number of cars on a freeway onramp. Add too many cars at once, and what happens? The onramp backs up. People still make it to the freeway, but it’s slow going (and frustrating!).

For a big website like PlanetMagpie (400+ pages, some with as many as 5 dynamic data controls per page)? That translates to a LOT of data calls. Every day.

Moving a Website to its Own Server: The Next Step in Performance Tuning

Originally we intended on just moving PlanetMagpie.com. But after looking at server logs for activity between the Sitefinity application and its database, we decided to put the CMS database on its own server too.

Moving the site to its own server devoted all of that server’s resources to running Sitefinity. Same with moving the CMS database to its own server. Together, both servers could allocate every resource available to data calls.

That added a whole new level of performance. If the initial tuning cut PlanetMagpie.com’s load time in half, dedicating servers cut it down a further 75%!

Cost-Prohibitive? No, Thanks to Virtualization

You might think, “That’s too expensive. We can’t put in a whole new server just for one website!”

We have virtualization to thank for making this cheaper (and so do you). The new server setup is structured like this:

A. Hyper-V Virtual IIS 7 Web Server

|

\PlanetMagpie.com

B. Hyper-V Virtual SQL Server Database

All of that, hosted on virtual servers in one physical server. We even have several other CMS websites on the same machine (in separate virtual servers).

When we started, average load time was 15-20 seconds. Performance tuning brought it down to about 10 seconds.

After moving onto its own web server? PlanetMagpie.com loads in an average of 3 seconds.

Dedicating a Server (or Two) Drops Load Times like a Brick

Improving communications between the CMS and its database brings some of the best performance increases. Especially Sitefinity sites. You can tune the hosting servers, you can move up to dedicated servers, or you can do both!

(The next step up from here would involve server farms for a website and its database. We don’t need to do that yet, but it’s something to consider for large volume/high-availability websites.)

Don’t go nuts with dynamic data controls either. Remember the onramp analogy. The more bells & whistles you build into pages, the more you’ll see slowdowns.

Would Moving Your Sitefinity-Based Website to its Own Server Double Performance?

Leave a Reply

Your email address will not be published. Required fields are marked *