An Application Pool is a mechanism used by IIS to isolate Web Applications, allowing you to have different configurations (security, resource usage, etc) and preventing misbehaving applications from interfering with other applications.
Generally, each Application Pool corresponds to one worker process. A worker process is a windows process (w3wp.exe) which runs Web Applications, and is responsible for handling requests sent to a Web Server for a specific application pool.
Recycling means the worker process that handles requests for that application pool is terminated and a new one started. This is generally done to avoid unstable states that can lead to application crashes, hangs, or memory leaks.
By default IIS will use overlapped recycle method, which keeps the old process up until the current requests are finished processing (or a set timeout elapses) while the new process handles new requests. This ensures service continuity so that you usually do not notice a recycle.
Go to Start -> Administrative Tools -> Internet Information Services (IIS) Manager. Expand the server and the “Application Pools” Group. Right-click the Application Pool you wish to configure and select “Properties”. In the first tab you will find the recycling settings.
Go to Start -> Administrative Tools -> Internet Information Services (IIS) Manager. Expand the server and click on “Application Pools”. In the center window right-click the Application Pool you wish to configure and select “Recycling...” ( be careful not to click “Recycle...” which will start a recycle).
You will be shown a two-step “wizard”. In the first half you will select which settings to use and in the second, which you want to log (in windows event logs) in case they are triggered.
You can check the base initial recommended values for an OutSystems Platform Installation in the Installation Checklist .
These values are only initial guidelines: you should fine-tune your memory configuration by collecting performance data  from each application pool and adjusting these values accordingly.
The values should be:
- High enough not to cause unnecessary recycles under load;
- Low enough that the recycle is triggered before it affects other application pools.
After collecting data on real-world usage, you can parcel the available memory proportionally between the application pools. You should review these values periodically as the usage of your applications changes or you deploy new applications.
You have two application pools: OutSystemsApplications and ServiceCenterAppPool. Real-world usage data shows that the maximum consumed memory for the former is 700MB and for the latter (even when publishing a large solution) is 300Mb.
If your server has 4GB of memory (the minimum recommended), you should set aside some for the operating system and divide the remaining among the application pools as follows:
- OS: 1GB
- ServiceCenterAppPool: 900MB
- OutSystemsApplications: 2100MB
 You can use the method described in the post below to collect memory usage data. You only need to use the “Process\Private Bytes” counter for all the w3wp processes instead of the counters referred in the post. http://www.outsystems.com/forums/discussion/10298/identifying-application-related-processor-overload-under-the-net-stack/
Obtain the most up-to-date version of this article here: