Tuning for the IIS. Microsoft delivers its Internet Information Services, in short
Tuning for the IIS. Microsoft delivers its Internet Information Services, or
May 4, 2017 | Author: Manuela Beck | Category: N/A DOWNLOAD PDF (864.6KB) Share Embed Donate Report this link
Short Description
Download Tuning for the IIS. Microsoft delivers its Internet Information Services, short…
Description
Fot o : S h u t t e r s t
Ock / Il
In Se
Rg ey
With the IIS and ASP.NET reacts in milliseconds
Tuning for the IIS The IIS likes to wait for one or two seconds. But this can be changed.
Icrosoft delivers its Internet Information Services, short IIS, already with the operating system. Therefore it is obvious to use it as well. But for many developers the IIS reacts too slowly. This can have different reasons, for example a complex authentication or too few hardware resources. But even with enough hardware. The simplest authentication can still be delayed. This is mostly due to some preset parameters.
Application pool idle timeout In order not to block resources, IIS is set to shut down processes that have not been active for a certain amount of time. These processes are the application pools, which can be identified in the task manager by the name w3wp. Exe can be seen (Figure 1). Each application pool processes requests for the web pages and web applications,
That belong to it. It is common practice to run multiple application pools in order to isolate web pages from each other and thus gain more stability and security. In the application pool process the ASP.NET code executed. Thus, when this process is terminated, the ASP.NET code removed. This is one of the reasons why requests sometimes take a little longer to process. If the application pool process was terminated, the next request must first create a new pool and the constructors of the code in the pool are executed. This can take a few seconds. The easiest way to get around this wait is to not stop the process when it is idle. To do this, set the idle timeout to zero minutes. By default, the process is stopped after 20 minutes. If one changes the value to zero minutes, this does not happen, all- ▶
However, the process then continues to occupy resources. Therefore you should consider exactly for which application pool it makes sense that it continues to exist even in idle mode, because otherwise changing the idle timeout can quickly lead to a shortage of resources.
Application Pool Autostart A more exciting feature in terms of response time of a web page or web service is the Autostart. This function came with .NET 4 and is available from IIS 7.5 available, i.E. With Windows 7 or the Windows Server 2008 R2. The IIS 7.5 must be set around the Application Initialization Mo dule [1] can be extended. In the IIS 8 it is installed ex works. Without the autostart an application pool process is only created when a request is made. Thus, the requestor must inevitably wait until the process has been created and all necessary actions have been taken The processes of the application pools are in the task manager at the designation nen are carried out, before it an Ant- w3wp.Exe (Fig. 1) word is received. This can be avoided by using the autostart feature, which restarts the process immediately after it has been terminated. Can replace this functionality. Of course, considering the amount of data required for some web applications, the autostart can also leave the idle timeout active, applications are loaded or prepared in the constructor anyway after the process is idle – the autostart can save the user a lot of time waiting for a new one to be started. Nevertheless, the idle tisparen. Also the Aufmeout used by some developers at least be increased, if it not completely abgewärmfunktionen, which regularly a request send, remains switched off. Otherwise, in order to ensure that the web application is ready, the web application will timeout completely every 20 minutes by default
$$ Advanced settings without autostart If the Application Initialization Module has been installed later, it happens that the entry Start Mode is not found in the advanced settings for the application pool. However, IIS Manager also provides another way to change the settings of an application pool. For this one opens the feature view on server level. Selects the configuration editor. In this editor you can edit the different sections of the configuration. For the application pools change to the section system.Applicationhost/applicationPools and open the first enumeration. The listing editor opens. You can see all application pools. Here you can now also find the startMode setting. Can these be set to AlwaysRun Change ning. Also the setting preload enabled is then mostly not found in the advanced settings of the page. The easiest way to access this is directly from the IIS configuration files. Under Windows\System32\inetsrv\config you will find
The file applicationHost.Config, in which the application pools are configured as well as the pages. In this file the setting preloadEnabled="true" must be set are entered. Here is an example:
Rebuilt, which may require more resources than intended. Application pools that start automatically consume resources all the time. However, usually a bit less than if just the idle timeout was disabled, since the processes freshly created during autostart only need a minimal amount of memory. However, the autostart feature brings the greatest benefit to the user in terms of response times – despite the constantly required resources. The autostart function is activated in the advanced settings of the respective application pool.
To the web page. This uses a URL pointing to the default page of the web application and discards all outgoing data from IIS. By this call for example the global.Asax is executed, which uses the ASP .NET Web API initialized. So to use the autostart really effectively, the item Preload enabled should be set to true in the advanced settings of the page. Autostart also allows the user a more restrictive resource management without a loss of response time than would be the case if simply disabling the idle timeout would be used. If this does not work for you as described, you can find an alternative solution in the Advanced settings without autostart box. Anyone using an IIS version prior to 7.5 is used, should also note the box Automatically start and start mode.
Resource Management
Advanced settings: AlwaysRunning startup mode (Figure 2)
After setting the application pool to AlwaysRunning (Figure 2) – if not already present – a process called w3wp.Exe started, which can be tracked in the task manager. This setting ensures that the application pool process is always running, but the first request still takes longer to complete. This still occurring wait time has its reason in the code of the web application. In case of an ASP.NET Web API, this is, besides a possible constructor in the controller, the actual application start and the configuration of the routing. But the initialization of the web application can also be done directly at autostart. However, it is not the application pool that is responsible for this, but the website itself. You can define for each website or web application whether the function preloading is activated in the advanced settings or not. This functionality ensures that the IIS makes a request for the application pool after the process has been created
More resources are consumed by the response time improvement features mentioned so far, i.E. Idle timeout and autostart. Therefore, you should also think about this . Basically the usage of the CPU should not have changed much. If too short idle timeout intervals were chosen, this causes the application pool process to be rebuilt more often, and depending on the code in the application pool, this requires CPU resources. This can be quickly adjusted by simply increasing the idle timeout accordingly. There is an option in the advanced settings for the application pool to limit the application pool in CPU consumption. You can define a threshold and determine what should happen when it is reached. For example, the process can be throttled when the server is under load. This does not lead to better response times, but rather to the opposite. The memory is the most affected resource by switching to autostart respectively changing the idle timeout. This is now continuously occupied by the application pool process. In the advanced settings for the application pool you can find properties to control that the process of the application pool is automatically recycled when a certain memory usage is reached. Recycling the process is nothing more than a restart. However, IIS ensures that new requests are only allowed on the new process when it is operational. Here also the setting preload enabled takes effect, whereby the new process is not considered ready until the fake request has been made. So for a short time you have two processes for the respective application pool, but this also means no loss of response time when reusing the application pool. This overlapping can also be deactivated. But then the request has to wait until the old process is finished and the new one is ready. If one calculates that there are several processes for the period of a few requests, one can respond to this and do this ▶
And do not have to disable this functionality.
ASP.NET Web API
$$ Response time in milliseconds
Test run 1
Test run 2
720 Now that all settings are known 700 to improve the response time of the 600 IIS, one should also design the 514 514 504 code to be executed in such a way that 500 454 it does not generate any unnecessary waiting time 400. There is for .NET some frameworks, with which you can write web applications 300 208. 195 191 200 A manageable number of them 100 comes from Microsoft itself. The Windows 17 8 Communication Foundation (WCF) is rather heavyweight in terms of Weban1. Call mean 1. Recycle 2. Recycle 3. Recycle applications, and with its many evaluation of test runs: On average, half the time was saved (Figure 3) possibilities it brings some dotnetpro 9/2015 configuration effort. For small and fast web applications, it is usually advisable to use the lightweight from the ASP.NET Framework, the Web API. Work and combines the asynchronous methods of the HttpClient The Web API was developed with ASP.NET MVC 4 released, bwith the Serializer from Newtonsoft.Json. Thus, the siert on the routing of ASP.NET and is also completely ohWeb API with only little code address, which is also usable for the ne MVC. Microsoft distributes the framework via the test scenario used in this article. Another, package manager NuGet. Developers the start. The late to update the packages. Makes tere work simple. The Web API is a good alternative to WCF when it comes to building the test scenario HTTP endpoints. It is fast furnished and offers There are certainly many use cases, in which a fast nevertheless a quantity of possibilities for adaptations and and above all fast reacting Web application needs extensions. The ASP.NET Web API does not give an architect. For this article a simple test scenario was ertur before, can be used however as RESTful service and/or thought: It concerns to build by JSON information over a country way. In addition, it provides its own client, which to get. The user of the web application wants to get anebenfalls via NuGet [2]. This is based on the hand of the top-level domain learn which country it reSystem.Net.Http.Httpclient from the current .NET frame, and also get the languages of the country and some other information. The data are available as XML files and are loaded into $$ Start automatically and Start mode the memory when the service is started; this saves unnecessary IO accesses to the hard disk or a database respectively. In older IIS versions – that is, all versions prior to IIS 7.5 – for such a manageable amount of data as a list, there is a function similar to autostart, but not so of all countries the memory is not too much loaded. While the entry Startup Mode AlwaysRunning tet. Conceivably it would be also to hold user data or profiles in the process of the application pool automatically starts and memory, since also this quantity usually in one also directly start routines in the code executes, becomes with the entry manageable framework remains. So that the cache is made much less when autoAutomatically start. The feature Auto The method responsible for this in the Application_Start section after creating an application pool or after restarting IIS must start the respective application pool.Asax to be called. Pool is started automatically, which would otherwise be started manually This is exactly the part of the autostart where it would have to be started on it. Default is Automatically start comes that at the page providing the web service with true. In current IIS versions this parameter is not the preloading is enabled. With the help of a log entry in more to be found under the advanced settings. The method Application_Start is a good way to test the IIS configuration editor or the direct access to the IISon, because this way it is possible to check if the configuration files are still accessible. The constant setting. Ructors of the individual controllers of the Web API are called only if these are addressed for the first time.
9.2015 www.Dotnetpro.En
Workout IIS
In order to keep the network traffic as low as possible and not to have resulting delays in the result, the Web API was hosted on an IIS located in the adesso network. The client was also in this network. With the help of the system.Diagnostics.Stopwatch measured the query speed. To measure the speed of the complete query with the Web API client, not only the time from creating the request to receiving the response was measured, but also the deserialization of the data. Here is the corresponding code snippet: stopwatch.Start; HttpResponseMessage response = await client.Getasync(queryString); if (response.Issuccessstatuscode) countryInfo = await response.Content.Readasasync; stopwatch.Stop;
Result and conclusion The described test scenario was run several times with different settings. The determined values were always the same. It was recorded how long the query takes at the first call. After that 100 more calls were made. From this an average value is calculated. While the queries were running, the application pool was restored three times and the resulting delay was recorded. For each test run web page. Application pool restarted. In the first test run, the start mode was set to OnDemand and preloading was activated on false. These settings resulted in the expected delays when first invoked and also immediately after recycling. The second test run differs only in that the startup mode was set to AlwaysRunning, but this did not result in any noticeable change compared to the first test run. This is why this test run is not shown in the diagram in Figure 3. In the third test run, preloading enabled was then also set to true and you can see that the delay has been more than halved by reusing the application pool process. Even the first request has become significantly faster. However, the difference between a request for reusing. A repeated request still clearly visible. Here the further optimization must be done in the code, because the IIS already prepares the web application as much as it can. Even large queries at the start of a web application can be executed in the background before a request is sent to the new instance of the web application. In a productive application, using the settings in IIS and keeping the data in a cache, a constant response speed could be achieved that stays below 50 milliseconds, even after the revert-
Www.Dotnetpro.En 9.2015
$$ Automatically terminate application pool In IIS, there is a security feature that ensures that the application pool is terminated. This will cause the web applications running under the application pool to stop working. If you want to reach the web application or web page, you only get the error 503 Service Un available to see. In the overview of the application pools in the IIS Manager you can see that the application pool has been stopped, and here you can also start it again. The security feature that stopped the application pool can be found in the advanced settings under protection for fast errors . This function ensures that the application pool is terminated if a certain number of errors occur within the set error interval (default: 5 minutes). Especially in development environments it makes sense to disable this feature. In live operation they should be left active. But it is recommended to use a notification when the application pool is terminated. Either via the entry written to the Windows event logs or directly via the advanced settings of the application pool. It is possible to have a file executed when the application pool is terminated in case of error. To avoid that several websites and web applications are directly affected by such an emergency shutdown, it is recommended to use several application pools.
Turning the application pool. The IIS can therefore be used without hesitation. Properly configured, the IIS also proves to be responsive. In the end it depends on how and with what you write the application that the IIS should provide, because here – depending on the architecture – the biggest gain in speed can be achieved. Especially in combination with the lightweight ASP.NET Web API, the IIS can shine. ◾ [1] Application Initialization Module for IIS 7.5, www.Dotnetpro.En/SL1509IIS1 [2] NuGet package Microsoft ASP.NET Web API 2.2 client, www.Dotnetpro.En/SL1509IIS2 [3] Documentation on ASP.NET Web API, www.Asp.Net/web-api
Sascha Werheid works at adesso AG in Cologne as a software engineer. His main focus is on the Microsoft environment, where he has worked extensively for more than eight years with the .NET Framework employs.