When deploying your Silverlight application out to your customers, there are a number of points that could become bottlenecks. Looking at it at a high level there are 3 main ones

  1. Getting your files to the client (.xap + other media)
  2. Processing requests
  3. Retrieving data

Lets tackle these in order

Getting your files to the client

Having the client download your application can become the first problem you encounter. If the user is sitting there, watching a loading screen for 5 minutes, they will most likely just move onto another site. Your application can be split up into the .net code, and the supporting files (.jpgs, etc.)

For this we can use ‘Windows Azure Storage’ + the ‘Content Delivery Network’ (CDN) to help us push the bits to the end user. An official overview and how to set it up can be seen on the Azure CDN website. But to sum it up, you can put your .xap files and your supporting files onto Azure storage, then enable CDN on your account. Azure CDN will then push the files out to servers around the world (currently 18 locations). When a users requests the files, they will download it from the closest server reducing download times.

image

The loading time of your application can be further reduced by cutting your application up into modules. This way instead of downloading a 10mb .xap file, the end user can just quickly download the 100k core application, meanwhile the rest of the modules can be loaded using MEF, Prisim or something similar. These other modules can also be put onto the Azure CDN (they are just additional .xaps after all!). Brendan Forster has a quick overview on what MEF is. But there are plenty of tutorials out there on how to integrate MEF into Silverlight.

Processing requests / Retrieving data

Most Silverlight applications will require information from somewhere to operate, it could be the current stock prices, an employee record or the weather forecast. This is the ‘backend’ of your Silverlight application. Azure can help you to scale your backend through its computational scaling. A simple way to do this is by exposing your backend services as a WCF or WCF RIA service. These are stateless services which make them very simple to scale!

image

Once you have create your service, put it into a web role. From there you can tell Azure to scale the number of instances up and down based on the usage of your application.

Retrieving data

Your service is going to need to store the data somewhere. Azure storage tables are one option, but for this example it is easiest to use SQL Azure. SQL Azure ‘acts’ pretty much like standard SQL Server 2008, except the server is being hosted in Microsoft’s data centres. Once you have created the database on their server, all you need to do is paste the connection string into your code. That is it, just a connection string. This means now we can use LinqToSql directly onto SQL Azure. All of your standard code will still work how you would expect it to.

image

Summing up

Putting these 2 technologies is fairly simple. Depending on your application architecture you can use any and all of these solutions offered here to create an application. In fact we could create an entire scalablee service in about 10minutes.

  1. Create the DB
  2. Create the LinqToSql entities using the SQL Azure connection string
  3. Create a ‘WCF RIA Services’ domain service, allow it to auto generate the code.
  4. Your entire backend is done
  5. Hook Silverlight into your service

By David Burela