Handling High Deployment Server Load

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
To create client business applications using current Microsoft technologies, see patterns & practices' Prism.

For low-to-moderate load scenarios, you will probably publish your applications to a single deployment server and provide your users with the link to the deployment manifest. However, if you are part of a large organization, this can cause problems when it is time to roll out new applications or updates. If you release an update and thousands of workers come to work first thing in the morning and start trying to download that update, two things could happen. First, the deployment server might be put under a tremendous load, depending on the size of the update and the number of users. Second, if you are automatically updating the application before it starts, it could take a long time for the application to download the update and then start on the user's computer.

There are several ways to address these issues:

  • Network load balancing. You could place the ClickOnce publication on several identically configured servers with the same network address. This way, it would be transparent to the users and to the ClickOnce addressing that the load is distributed across multiple servers. This would address both initial deployment and updates.
  • Publish to multiple servers. You could publish the application to more than one server and have different parts of the organization download and launch the application from different physical addresses to manually distribute the load. This would address both initial deployment and updates. This would also address the staged deployment scenario discussed in Deploying for Multiple Groups.
  • Download updates in the background. You could use the ClickOnce programmatic API to check for updates and download them on a background thread. This would not reduce the load on the server, but it would make it so the users do not have to wait for the update to occur before starting the application. This would address only updates; it would not help with initial deployment of new applications.
  • Download updates in the background on a random/variable schedule. You could use the ClickOnce programmatic API to check for updates and download them in the background but have the checks and downloads happen at different times for different client computers. This could be done with a random wait period in the update code or a remote scheduling service that the client computer calls out to before trying to check for downloads. This would address only updates; it would not help with initial deployment of new applications. But it would reduce the load on the server.
Show: