Features of the Windows Process Activation Service (WAS)

The Windows Process Activation Service (WAS) of IIS 7 is the key component that provides process model and configuration features to Web Applications and Web Services. WAS major task is to manage Application Pools. Application Pools are configuration containers that represent the hosting environment for groups of URLs.

When an HTTP client requests a URL HTTP.SYS maps the request to an Application Pool request queue. A worker process for the Application Pool request queue is spawned by WAS and the worker process executes the code necessary to send a response. One of WAS’s main tasks is to manage the worker processes it spawned, i.e. WAS monitors their health, recycles them if necessary and makes sure none of them consume more resources than specified in the corresponding AppPool configuration. WAS is also the arbiter and collector for run-time and state data, e.g. performance counters, site and Application Pool state.

Architectural Diagram

Process Model Features

Supporting 10000 or more web sites to be hosted on the same physical machine is a core requirement for today’s mass hosting environments. The code running on these web-sites is usually not well tested, if at all. To support these requirements WAS needs to provide a powerful process model and efficient resource management.

Efficient Resource Management

On-Demand Activation

Resources like RAM and CPU are scarce in multi-tenant scenarios. WAS will start an IIS worker process only once requests for a particular web site or web application arrive.

Idle-timeout

Because resources are usually scarce WAS can shutdown web applications based on a configurable idle-timeout.

Health Monitoring

To ensure their health WAS monitors the worker processes it spawned. Health messages are periodically sent to each running worker process. If the worker process doesn’t respond in a configurable time interval the worker process will be recycled or killed. This way undetected deadlocks in worker processes get automatically fixed by restarting the worker process.

Startup Limit

Part of the Rapid-Fail Protection feature is the Startup limit. If a worker process doesn’t report back to WAS within the configurable startup-limit it will be killed and the Rapid-Fail-Protection counter is incremented. Application Pools are stopped, i.e. restarting the worker process will not be tried anymore, if the Rapid-Fail-Protection counter reaches a configurable limit within a configurable time limit. This prevents scenarios where worker processes hang or crash during startup.

Shutdown Limit

A worker process also has to shutdown in a configurable limit. If the shutdown doesn’t happen in this time the worker process gets killed by WAS. This prevents resource overuse due to processes hanging in their shut-down phase. Additional shutdown settings allow an executable to be started (e.g. a debugger) when the shutdown doesn’t complete within the allotted time.

CPU affinity

Configuration settings allow WAS to start worker processes that are affinitized to one or more CPUs. This prevents tenants from interfering with each other if they share the same physical machine.

User Profile

WAS can start worker processes with or without loading the user profile.

Security

Application Pool Identity

IIS worker processes can run as a custom account, built-in account (LocalService, LocalSystem, NetworkService), or application pool identity (default). Using application pool identity is recommended because it does not require password management and application pool identities already abide to the principle of least privilege. Built-in accounts don’t require password management as well. If a custom user identity is used, the password is automatically encrypted. Configuration settings can be replicated to multiple machines by sharing the configuration encryption keys across machines.

Job Object Features

Job objects allow administrators to restrict worker processes to a particular CPU limit. A configurable action is taken if this CPU limit is exceeded. Job objects will also make sure that processes spawned by the worker process get terminated.

Configuration Isolation and Security

Before WAS starts an Application Pool and its worker process it generates a unique configuration file for this Application Pool. Application Pools also have configuration settings to run Application Pools under unique identities. Isolation can be achieved however even if the same identity is used. WAS creates a unique Security Identifier (SID) for each Application Pool. The Application Pool configuration file is then secured with this unique SID. This ensures that Application Pool configuration files can only be read by Administrators and the Application Pool itself. Even file permissions can be configured using this unique SID.

Diagnostics and Monitoring

Event Logging

Events regarding invalid configuration, recycling, startup or shutdown of worker processes are reported to the System Eventlog.

Currently Executing Requests

WAS exposes a run-time and state control interface that allows scripts and tools to query for the currently executing requests of a particular worker process. This is useful to find requests that hang or requests that take a very long time to complete.

Performance Counters

All IIS performance counters get funneled through WAS. WAS gathers these performance counters because IIS counters are site-based and web applications can live in different Application Pools.

Recycling

Recycling allows the refresh of worker processes without losing a single request due to down-time. This is done via a feature called «overlapping recycling».

Overlapping Recycling

WAS does this by spawning up a new worker process parallel to the old one that is still handling requests. Once the new worker process is up it starts picking up requests from the request queue while the old worker process is instructed by WAS to stop picking up requests. Once the old worker process finishes all executing requests it shuts down. This feature is called «overlapping recycling». It ensures that no requests are lost during a recycle.

Recycling Configuration

Recycling parameters are configurable in the IIS configuration system.

Scheduled Recycling

Customers might want to recycle their applications based on a regular schedule. Via configuration settings recycling can be scheduled periodically, e.g. every 4 hours, every day at 1am etc.

Recycling based on Memory Consumption

Applications might leak memory over time. WAS can monitor the memory consumption of each worker processes to ensure that no worker process uses more than its preconfigured limit. Reaching a configured virtual or private memory threshold will trigger the recycling of a worker process.

Recycling Based on Number of Requests

Recycling can also be configured based on the number of requests a particular worker process handled.

Custom Recycling

Custom code can custom health statistics and trigger a recycling via an API call to the WAS run-time and state API’s.

Process Orphaning

Some errors only happen in a production environment. Killing worker processes ensures up-time but troubleshooting of these errors becomes difficult, e.g. if the failing worker process needs to be debugged. The process orphaning feature in WAS allows worker processes to be recycled without killing the failed worker process. Now a debugger can be attached to it. Additional process orphaning settings allow the execution of a process (e.g. a debugger) if orphaning happens.

Application Pool State Management

Application Pools can be stopped, recycled or started via publicly available API’s, e.g. if an application has to be taken offline or if recycling has to be done based on parameters different from what’s configurable in the applicationhost.config file.

Additional WAS Features

Load-Balancer Features

HTTP.SYS still listens on the network and will return a 500 HTTP error message if requests are not picked up by an Application Pool. This is a problem because for a Level 5 Load Balancers (TCP/IP) a 500 HTTP error looks like a valid TCP/IP connection. A WAS configuration setting can enable HTTP.SYS to reject connections instead of sending HTTP responses.

WAS can be configured to start worker processes with the following settings:

WoW64 Support

WAS can start 32-Bit or 64-Bit worker processes.

.NET Framework Preload

WAS can be configured to preload a particular version of the .NET Framework. This can make the troubleshooting of version conflicts much easier.

Web Gardens

A Web Garden is the term for an Application Pool that runs with multiple worker processes. Requests get distributed among these worker process instances using a round-robin mechanism.

Требуется компонент «Служба активации процессов Windows — модель _ процесса» LonghornWASProcessModelInstalled The Windows Process Activation Service — Process Model component is required_LonghornWASProcessModelInstalled

Применимо к: Exchange Server 2013 Applies to: Exchange Server 2013

Содержимое этой статьи не обновлялось для Microsoft Exchange Server 2013. Несмотря на отсутствие обновления, оно может быть применимо для Exchange 2013. Если вам все еще нужна помощь, ознакомьтесь с указанными ниже ресурсами сообщества. The content in this topic hasn’t been updated for Microsoft Exchange Server 2013. While it hasn’t been updated yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.

Возникли проблемы? Having problems? Обратитесь за помощью к участникам форумов Exchange. Ask for help in the Exchange forums. Посетите форумы по Exchange Server. Visit the forums at Exchange Server.

Exchange Server 2010 не удается продолжить установку на компьютере с Windows Server 2008 или Windows Server 2008 R2, так как на сервере не установлена функция «Служба активации процессов Windows — модель процессов». Exchange Server 2010 setup cannot continue installation on the Windows Server 2008-or Windows Server 2008 R2-based computer because the Windows Process Activation Service — Process Model feature is not installed on the server.

Служба активации Windows обобщает модель процесса служб IIS, устраняя зависимость от протокола HTTP. Все возможности служб IIS, доступные ранее только HTTP-приложениям, теперь доступны приложениям на базе служб WCF через протоколы, отличные от HTTP. Кроме того, Служба активации Windows используется в службах IIS 7.0 для активации на основе сообщений через HTTP. The Windows Process Activation Service generalizes the Internet Information Services (IIS) process model, removing the dependency on HTTP. All the features of IIS that were previously available only to HTTP applications are now available to applications hosting Windows Communication Foundation (WCF) services, by using non-HTTP protocols. IIS 7.0 also uses Windows Process Activation Service for message-based activation over HTTP.

В компоненте «Модель процесса» размещены веб-службы и службы WCF. Компонент «Модель процесса», впервые представленный в службах IIS 6.0, представляет собой новую архитектуру с улучшенной защитой от сбоев, а также возможностью наблюдения за работоспособностью и перезапуска. The Process Model hosts Web and WCF services. Introduced in IIS 6.0, the Process Model is a new architecture that features rapid failure protection, health monitoring, and recycling.

Чтобы устранить эту проблему, установите на этом сервере функцию «Служба активации процессов Windows — модель процессов», а затем повторно выполните установку Exchange 2010. To resolve this issue, install the Windows Process Activation Service — Process Model feature on this server and then rerun Exchange 2010 setup.

Установка компонента «Служба активации Windows — Модель процесса» с помощью диспетчера сервера Install the Windows Process Activation Service — Process Model feature by using the Server Manager tool

Нажмите кнопку Пуск и выберите пункт Администрирование, а затем — Диспетчер сервера. Click Start, click Administrative Tools and then Server Manager.

В левой области навигации щелкните правой кнопкой мыши элемент Компоненты и выберите пункт Добавить компоненты. In the left navigation pane, right-click Features, and then click Add Features.

В области Выбор компонентов прокрутите список вниз до элемента Служба активации процессов Windows. On the Select Features pane, scroll down to Windows Process Activation Service.

Установите флажки для компонента Модель процесса. Select the check boxes for Process Model.

В области Выбор компонентов нажмите Далее, а затем в области Подтверждение выбранных элементов для установки нажмите Установить. Click Next from the Select Features pane, and then click Install at the Confirm Installations Selections pane.

Нажмите кнопку Закрыть, чтобы завершить работу мастера добавления служб ролей. Click Close to leave the Add Role Services wizard.

Размещение в службе активации процессов Windows Hosting in Windows Process Activation Service

Служба активации Windows (WAS) управляет активацией и временем жизни рабочих процессов, которые содержат приложения, размещенные в службах Windows Communication Foundation (WCF). The Windows Process Activation Service (WAS) manages the activation and lifetime of the worker processes that contain applications that host Windows Communication Foundation (WCF) services. Модель процесса WAS обобщает модель процесса IIS 6.0 для HTTP-сервера, удаляя зависимость от HTTP. The WAS process model generalizes the IIS 6.0 process model for the HTTP server by removing the dependency on HTTP. Это позволяет службам WCF использовать протоколы HTTP и отличные от HTTP, такие как net. TCP, в среде размещения, которая поддерживает активацию на основе сообщений и предлагает возможность размещения большого количества приложений на определенном компьютере. This allows WCF services to use both HTTP and non-HTTP protocols, such as Net.TCP, in a hosting environment that supports message-based activation and offers the ability to host a large number of applications on a given machine.

Дополнительные сведения о построении службы WCF, работающей в среде с размещением, см. в разделе как разместить службу WCF в WAS. For more information about building a WCF service that runs in the WAS hosting environment, see How to: Host a WCF Service in WAS.

Модель процессов WAS предоставляет несколько функций, благодаря которым размещение приложений можно осуществлять более надежным и управляемым способом и при этом более эффективно использовать ресурсы. The WAS process model provides several features that enable applications to be hosted in a way that is more robust, more manageable, and that uses resources efficiently:

Активация приложений на основе сообщений и динамические запуск и остановка приложений рабочего процесса в ответ на входящие рабочие элементы, поступающие по протоколу HTTP или по сетевым протоколам, отличным от HTTP. Message-based activation of applications and worker process applications start and stop dynamically in response to incoming work items that arrive using HTTP and non-HTTP network protocols.

Надежный перезапуск приложений и рабочих процессов для поддержания состояния выполняемых приложений. Robust application and worker process recycling to maintain the health of running applications.

Централизованные настройка приложений и управление ими. Centralized application configuration and management.

Возможность использования приложениями модели процессов IIS без развертывания полной установки IIS. Allows applications to take advantage of the IIS process model without requiring the deployment footprint of a full IIS installation.
Windows Server AppFabric работает с IIS 7,0 и службой активации Windows (WAS), чтобы предоставить обширную среду размещения приложений для служб NET4 WCF и WF. Windows Server AppFabric works with IIS 7.0 and Windows Process Activation Service (WAS) to provide a rich application hosting environment for NET4 WCF and WF services. К ее преимуществам относятся управление жизненным циклом, перезапуск процессов, совместное размещение, быстрая защита от сбоев, обработка потерянных процессов, активация по запросу и наблюдение за работоспособностью. These benefits include process life-cycle management, process recycling, shared hosting, rapid failure protection, process orphaning, on-demand activation, and health monitoring. Подробные сведения см. в разделе функции размещения AppFabric и Основные понятия размещения AppFabric. For detailed information, see AppFabric Hosting Features and AppFabric Hosting Concepts.

Элементы модели адресации WAS Elements of the WAS Addressing Model

Приложения имеют адреса универсального кода ресурса (URI), представляющие собой единицы кода, временем существования и средой выполнения которых управляет сервер. Applications have Uniform Resource Identifier (URI) addresses, which are the code units whose lifetime and execution environment are managed by the server. В одном экземпляре сервера WAS может размещаться много различных приложений. A single WAS server instance can be home to many different applications. Серверы организуют приложения в группы, называемые сайтами. Servers organize applications into groups called sites. Внутри узла приложения упорядочены иерархически, их расположение отражает структуру URI, выполняющих функцию их внешних адресов. Within a site, applications are arranged in a hierarchical manner that reflects the structure of the URIs that serve as their external addresses.

Адреса приложений состоят из двух частей: базовый префикс URI и относительный адрес конкретного приложения (путь), сочетание этих элементов дает внешний адрес приложения. Application addresses have two parts: a base URI prefix and an application-specific, relative address (path), which provide the external address for an application when joined together. Базовый префикс URI создается из привязки узла и используется для всех приложений в этом узле. The base URI prefix is constructed from the site binding and is used for all the applications under the site. После этого адреса приложений создаются путем создания фрагментов пути для конкретного приложения (например, «/Аппликатиононе») и добавления их к базовому префиксу URI (например, «net. TCP://localhost») для получения полного URI приложения. Application addresses are then constructed by taking application-specific path fragments (such as, «/applicationOne») and appending them to the base URI prefix (for example, «net.tcp://localhost») to arrive at the full application URI.

В следующей таблице приведены несколько возможных сценариев адресации для сайтов WAS с привязками сайтов HTTP и привязками сайтов, отличными от HTTP. The following table illustrates several possible addressing scenarios for WAS sites with both HTTP and non-HTTP site bindings.