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. |
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 in to work first thing in the morning and start trying to download that update, two things will happen. The first is that the deployment server may be put under a tremendous load, depending on the size of the update and number of users. The second is that it could take a very long time for the application to download the update and launch for each user if you are doing automatic updates before the application starts (this is the default behavior).
There are several ways to address this issue:
- Network load balancing. You could place the ClickOnce publication on several identically configured servers with the same network address and 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 earlier.
- 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 launching 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, not initial deployment, but it would also reduce the load on the server.
For more information, see How to: Share Files Across Multiple Versions and How to: Implement a Custom ClickOnce Deployment Server File Repository.
