|
Pooling IIS Execution Notes |
| Jesse Burkhardt |
1.) From MS, 25+ ASP Tips :
Tip 9: Out-of-Process Execution Trades off Performance for Reliability
Both ASP and MTS/COM+ have configuration options that allow you to trade off reliability for performance. You should understand these trade-offs when building and deploying your application.
ASP Options
ASP Applications can be configured to run in one of three ways. With IIS 5.0, the terminology "isolation level" has been introduced to describe these options. The three isolation level values are Low, Medium, and High:
Low Isolation. This is supported in all versions of IIS and is the fastest. It runs ASP in Inetinfo.exe, which is the primary IIS process. If the ASP application crashes, so does IIS. (To restart IIS under IIS 4.0, Webmasters would monitor the site using tools such as InetMon, and fire off batch files to restart the server if it failed. IIS 5.0 introduces reliable restart, which automatically restarts a failed server.)
Medium Isolation. IIS 5.0 introduces this new level, which is referred to as out-of-process, since ASP runs outside of the IIS process. In Medium isolation, all ASP applications configured to run as Medium share a single process space. This reduces the number of processes required to run multiple out-of-process ASP applications on one box. Medium is the default isolation level in IIS 5.0.
High Isolation. Supported in IIS 4.0 and IIS 5.0, High isolation is also out-of-process. If ASP crashes, the Web server doesn't. The ASP application is automatically restarted on the next ASP request. With High isolation, each ASP application that is configured to run as High runs in its own process space. This protects ASP applications from each other. Its drawback is that it requires a separate process for each ASP application. This can add up to a lot of overhead when dozens of applications need to be hosted on one box.
Which option is the best? In IIS 4.0, there was a fairly steep performance penalty for running out-of-process. In IIS 5.0, a lot of work was done to minimize the cost of running ASP applications out-of-process. In fact, in most tests, ASP out-of-process applications in IIS 5.0 run faster than in-process applications in IIS 4.0. Regardless, in-process (Low isolation level) still produces the best performance on both platforms. However, you won't see much benefit to the Low isolation level if you have a relatively low hit rate or low maximum throughput. Therefore, you should not feel the need to reach for the Low isolation level until you need hundreds or thousands of pages per second per Web server. As always, test with multiple configurations and determine which trade-offs you are willing to make.
Note When you run ASP applications out-of-process (Medium or High isolation), they run in MTS on NT4 and COM+ on Windows 2000. That is, on NT4 they run in Mtx.exe, and on Windows 2000, they run in DllHost.exe. You can see these processes running in Task Manager. You can also see how IIS configures MTS Packages or COM+ Applications for out-of-process ASP applications.
COM Options
COM components also have three configuration options, though not completely analogous to the ASP options. COM components can be:"unconfigured," configured as Library Applications, or configured as Server Applications. Unconfigured means that the component is not registered with COM+. The component will run in the caller's process space, that is, they are "in-process." Library Applications are also in-process, but benefit from COM+'s services, including security, transactions, and context support. Server Applications are configured to run in their own process space.
You may see a slight benefit of unconfigured components over Library Applications. You're likely to see a large performance benefit of Library Applications over Server Applications. This is because Library Applications run in the same process as ASP, whereas Server Applications run in their own process. Inter-process calls are more expensive than in-process calls. Also, when passing data such as recordsets between processes, all of the data must be copied between the two processes.
Pitfall! When using COM Server Applications, if you pass objects between ASP and COM, make sure that the objects implement "marshal-by-value," or MBV. Objects that implement MBV copy themselves from one process to another. This is better than the alternative, in which the object remains in the creator's process, and the other process calls repeatedly into the creating process to use the object. Disconnected ADO recordsets will marshal-by-value; connected recordsets won't. The Scripting.Dictionary does not implement MBV and should not be passed between processes. Finally, a message to VB programmers out there: MBV is NOT achieved by passing a parameter ByVal. MBV is implemented by the original component author.
What to Do?
If we were to recommend configurations with reasonable trade-offs of performance versus reliability, they would be as follows:
On IIS 4.0, use ASP's Low Isolation level, and use MTS Server Packages. On IIS 5.0, use ASP's Medium isolation level, and use COM+ Library Applications. These are very general guidelines; hosting companies generally run ASP at Medium or High Isolation level, whereas single-purpose Web servers can be run at Low isolation. Measure the trade-offs and decide for yourself which configuration meets your needs
Tip 9: Out-of-Process Execution Trades off Performance for Reliability
Both ASP and MTS/COM+ have configuration options that allow you to trade off reliability for performance. You should understand these trade-offs when building and deploying your application.
ASP Options
ASP Applications can be configured to run in one of three ways. With IIS 5.0, the terminology "isolation level" has been introduced to describe these options. The three isolation level values are Low, Medium, and High:
Low Isolation. This is supported in all versions of IIS and is the fastest. It runs ASP in Inetinfo.exe, which is the primary IIS process. If the ASP application crashes, so does IIS. (To restart IIS under IIS 4.0, Webmasters would monitor the site using tools such as InetMon, and fire off batch files to restart the server if it failed. IIS 5.0 introduces reliable restart, which automatically restarts a failed server.)
Medium Isolation. IIS 5.0 introduces this new level, which is referred to as out-of-process, since ASP runs outside of the IIS process. In Medium isolation, all ASP applications configured to run as Medium share a single process space. This reduces the number of processes required to run multiple out-of-process ASP applications on one box. Medium is the default isolation level in IIS 5.0.
High Isolation. Supported in IIS 4.0 and IIS 5.0, High isolation is also out-of-process. If ASP crashes, the Web server doesn't. The ASP application is automatically restarted on the next ASP request. With High isolation, each ASP application that is configured to run as High runs in its own process space. This protects ASP applications from each other. Its drawback is that it requires a separate process for each ASP application. This can add up to a lot of overhead when dozens of applications need to be hosted on one box.
Which option is the best? In IIS 4.0, there was a fairly steep performance penalty for running out-of-process. In IIS 5.0, a lot of work was done to minimize the cost of running ASP applications out-of-process. In fact, in most tests, ASP out-of-process applications in IIS 5.0 run faster than in-process applications in IIS 4.0. Regardless, in-process (Low isolation level) still produces the best performance on both platforms. However, you won't see much benefit to the Low isolation level if you have a relatively low hit rate or low maximum throughput. Therefore, you should not feel the need to reach for the Low isolation level until you need hundreds or thousands of pages per second per Web server. As always, test with multiple configurations and determine which trade-offs you are willing to make.
Note When you run ASP applications out-of-process (Medium or High isolation), they run in MTS on NT4 and COM+ on Windows 2000. That is, on NT4 they run in Mtx.exe, and on Windows 2000, they run in DllHost.exe. You can see these processes running in Task Manager. You can also see how IIS configures MTS Packages or COM+ Applications for out-of-process ASP applications.
COM Options
COM components also have three configuration options, though not completely analogous to the ASP options. COM components can be:"unconfigured," configured as Library Applications, or configured as Server Applications. Unconfigured means that the component is not registered with COM+. The component will run in the caller's process space, that is, they are "in-process." Library Applications are also in-process, but benefit from COM+'s services, including security, transactions, and context support. Server Applications are configured to run in their own process space.
You may see a slight benefit of unconfigured components over Library Applications. You're likely to see a large performance benefit of Library Applications over Server Applications. This is because Library Applications run in the same process as ASP, whereas Server Applications run in their own process. Inter-process calls are more expensive than in-process calls. Also, when passing data such as recordsets between processes, all of the data must be copied between the two processes.
Pitfall! When using COM Server Applications, if you pass objects between ASP and COM, make sure that the objects implement "marshal-by-value," or MBV. Objects that implement MBV copy themselves from one process to another. This is better than the alternative, in which the object remains in the creator's process, and the other process calls repeatedly into the creating process to use the object. Disconnected ADO recordsets will marshal-by-value; connected recordsets won't. The Scripting.Dictionary does not implement MBV and should not be passed between processes. Finally, a message to VB programmers out there: MBV is NOT achieved by passing a parameter ByVal. MBV is implemented by the original component author.
What to Do?
If we were to recommend configurations with reasonable trade-offs of performance versus reliability, they would be as follows:
On IIS 4.0, use ASP's Low Isolation level, and use MTS Server Packages. On IIS 5.0, use ASP's Medium isolation level, and use COM+ Library Applications. These are very general guidelines; hosting companies generally run ASP at Medium or High Isolation level, whereas single-purpose Web servers can be run at Low isolation. Measure the trade-offs and decide for yourself which configuration meets your needs
2.) From deja.com, Naveen Kholi, 2001-11-30:
LOW:
This is a very level security option. What this means is that your web application and all the associated componnets will be loaded in the internet server application (inetinfo.exe) prcoess space. ASP is nothing but a COM server that gets loaded when a user accesses your web application for the first time. And from then on it stays loaded as long as this application is running. So for LOW option this gets loaded in the internet server's address space. Very much like dll getting loaded into the caller's namespace. It is fast. But the problem with this is that if there is bug in one of your components and causes an exception or crash. Then it brings down your whole web server.
HIGH:
This is totally opposite of LOW. In this case ASP app gets loaded into a separate COM surrogate DLLHOST.exe. You can verify that by setting this option for web site and then access it. In the task manager you will see a new instance of DLLHOST gets started. The advantage of this is that your web app runs separate from Web Server process space. If any thing goes wrong in the web site, it stays isolated to that instance only. Your web server will not come down with it. The problem with this is that since app is runing in a separate process space, the access to objects is through proxy-stub, meaning overhead of marshalling. This option is good for testing purposes because then you don't have to worry about web server going down because of bugs or crashes.
MEDIUM:
This is the option that is set by default. In this case the pooled components are run in a single process out of InetInfo.exe space. And this process runs in a separate logon session. You can use this option to isolate the components that can be potential problems as pooled componnets. This way these components won't be running into the inetinfo.exe prcess space and runs in systen logon session.
LOW:
This is a very level security option. What this means is that your web application and all the associated componnets will be loaded in the internet server application (inetinfo.exe) prcoess space. ASP is nothing but a COM server that gets loaded when a user accesses your web application for the first time. And from then on it stays loaded as long as this application is running. So for LOW option this gets loaded in the internet server's address space. Very much like dll getting loaded into the caller's namespace. It is fast. But the problem with this is that if there is bug in one of your components and causes an exception or crash. Then it brings down your whole web server.
HIGH:
This is totally opposite of LOW. In this case ASP app gets loaded into a separate COM surrogate DLLHOST.exe. You can verify that by setting this option for web site and then access it. In the task manager you will see a new instance of DLLHOST gets started. The advantage of this is that your web app runs separate from Web Server process space. If any thing goes wrong in the web site, it stays isolated to that instance only. Your web server will not come down with it. The problem with this is that since app is runing in a separate process space, the access to objects is through proxy-stub, meaning overhead of marshalling. This option is good for testing purposes because then you don't have to worry about web server going down because of bugs or crashes.
MEDIUM:
This is the option that is set by default. In this case the pooled components are run in a single process out of InetInfo.exe space. And this process runs in a separate logon session. You can use this option to isolate the components that can be potential problems as pooled componnets. This way these components won't be running into the inetinfo.exe prcess space and runs in systen logon session.
