Best way to deploy website - App pool start stop or website start stop

Question

What is the best way to deploy changes to a website( replace the dlls and other required files) ?

Should the website be stopped and started or should the app pool be stopped and started?

I read that when a website is stopped, it still has the application state loaded in memory. In this case will the old request be served ? Can the dlls be replaced without any problem ? How does the content gets reloaded when the website is started?

When the app pool is stopped, will it continue to serve the old requests? If yes, how does the old request gets served considering the website is now containing the changed dlls?

Answer 1

What is the best way to deploy changes to a website( replace the dlls and other required files) ?

The best way is to use Web Deploy to automate the process. It automatically compares files and only replaces what is needed and deletes what is not needed, making it very fast, efficient, and reliable.

Should the website be stopped and started or should the app pool be stopped and started?

You typically don't have to do either. However, if you want to prevent access to your website during an upgrade and the upgrade is expected to take longer than a few seconds, then you could stop the web site and start another one that uses the same IIS bindings with an "Application Under Maintenance" message.

I read that when a website is stopped, it still has the application state loaded in memory. In this case will the old request be served ? Can the dlls be replaced without any problem ? How does the content gets reloaded when the website is started?

The HTTP protocol is stateless. So, most content that is updated will be reloaded from the new files on the server.

There are a few exceptions.

If you are using out-of-process session state, the state will be persisted even though the application is recompiled and reloaded. Typically, the data that you have in session state is something you want to survive an upgrade, though.

If you are using caching (System.Web.Caching or System.Runtime.Caching), the cached data will remain if you specified to make it "Not Removable". Typically, I use a single file for the application as a cache dependency so when that file is edited (or replaced) on the server, the cache will be reset.

Output caching has no cache dependencies. Normally it survives until the application pool is restarted. But, you could see this answer for a manual way to reset it without an application pool reset.

Cookies are stored on the remote client machines. Therefore, they will survive an upgrade intact.

Static files (images, css, and javascript files) are typically cached on the remote client machines. So when you do an upgrade, it is helpful to append a query string to the end of these URLs to ensure the cached file is not used. See this article for one such approach.

When the app pool is stopped, will it continue to serve the old requests? If yes, how does the old request gets served considering the website is now containing the changed dlls?

As I already mentioned, the HTTP protocol is stateless. The server will not replay any former requests that were made by clients. Once the client has received the repsponse, the server essentially forgets about them.

A lot of the way the web server handles an upgrade is determined by whether it is a web application or a web site (and if a web site, whether it has been precompiled). If the application is running during an upgrade, users that try to access it could see errors.

My advice is: don't worry about it. Schedule your upgrades for off-peak times. Use Web Deploy to automate the process to make the upgrade window as short as possible. And use the techniques above to ensure cached data and content is reset appropriately. In most applications, a few seconds or minutes of downtime in the middle of the night goes almost unnoticed.