How to: Specify a Port for the Development Server

In Visual Studio, you can select from several Web servers: IIS, IIS Express, or the built-in Visual Studio Development Server. For information about the differences between these servers, see Web Servers in Visual Studio for ASP.NET Web Projects.

By default, when you create a Web site or a Web application project in Visual Studio that uses IIS Express or the Visual Studio Development Server, a port is selected for the project. For example, if you are testing a page named MyPage.aspx, when you run the page using IIS Express or the Visual Studio Development Server, the URL of the page might be the following:

http://localhost:31544/MyPage.aspx

If you want to run the project on a specific port, you can configure the Web server to do so.

NoteNote
Visual Studio cannot guarantee that the port you specify will be available when you run your file-system Web site. If the port is in use when you run a page, Visual Studio displays an error message.

To specify a port for a Web site project that uses IIS Express

  1. In the Tools menu, select Options and then General.
  2. Make sure the Always Show Solution option is selected.
  3. In Solution Explorer, right-click the project name and then click Remove. This removes the project from your solution, but does not delete the corresponding files on disk.
  4. Click OK.
  5. In Windows Explorer, navigate to the IIS Express ApplicationHost.config file. By default, this is located in the following folder:%systemdrive%:\Users\<username>\Documents\IISExpress\config
  6. Open the ApplicationHost.config file in a text editor such as Notepad. In the sites section, search for the Web site name.
  7. In the bindings section for the Web site, change the port binding.The following example shows the bound port set to 40955.
    <site name="WebSite1" id="1">
       <application path="/" applicationPool="Clr4IntegratedAppPool">
          <virtualDirectory path="/" physicalPath="C:\WebSites\WebSite1" />
       </application>
       <bindings>
          <binding protocol="http" bindingInformation="*:40955:localhost" />
       </bindings>
    </site>
  8. Save the ApplicationHost.config file and close the text editor.
  9. In Solution Explorer, right-click the solution, select Add, and then select Existing Web Site.
  10. In the Add Existing Web Site dialog box, make sure that the Local IIS tab is selected.
  11. Under IIS Express Sites, select the site for which you have changed the port number, and then click Open.The project name contains the URL with the new port number for the Web site (for example, http://localhost:40955/). If the solution was created at the same time as the original Web site project, the previous port number will still be part of the solution name (for example, localhost_40954).
  12. To update the solution name to reflect the new port number, in Solution Explorer right-click the solution name, select Rename, and then specify a new name.
  13. On the File menu, click Save All.
  14. To verify the change, press CTRL+F5 to run the project.The new port number appears in the address bar of the browser.

To specify a port for a Web site project that uses the Visual Studio Development Server

  1. In Solution Explorer, select the project name.
  2. In the Properties pane, set Use dynamic ports to False.This enables editing of the Port number property.
  3. Enter a port number for the Port number property.
  4. Click outside of the Properties pane. This saves the property settings
  5. To verify the change, press CTRL+F5 to run the project. The new port number appears in the address bar of the browser.

To specify a port for a Web application project that uses IIS Express

  1. In Solution Explorer, right-click the name of the application and then select Properties.
  2. Click the Web tab.
  3. In the Servers section, under Use Local IIS Web server, in the Project URL box change the port number.
  4. To the right of the Project URL box, click Create Virtual Directory, and then click OK.
  5. In the File menu, click Save Selected Items.
  6. To verify the change, press CTRL+F5 to run the project.The new port number appears in the address bar of the browser.

To specify a port for a Web application project that uses the Visual Studio Development Server

  1. In Solution Explorer, rig
    ht-click the name of the application, and then select Properties.
  2. Click the Web tab.
  3. In the Servers section, under Use Visual Studio Development Server, select Specific port.
  4. Change the port number.
  5. In the File menu, click Save Selected Items.
  6. To verify the change, press CTRL+F5 to run the project.The new port number appears in the address bar of the browser.

via: http://msdn.microsoft.com/en-us/library/ms178109.ASPX

Troubleshooting badly behaving IIS application pools

There are many reasons why an application pools’ worker process (W3WP.exe) could be behaving badly.  The best approach is to capture some memory dumps during the problem situation and then analyze them.  The problem with that is the root cause is not always obvious, even after many hours of analysis and investigation.

An alternative to memory dump analysis, or maybe a prequel, is to capture and analyze the behavior of the worker process.  One of the simplest actions to monitor the application pool is to open up Task Manager and look at the PID of the W3WP.exe process, as illustrated in Figure 1.

Figure 1, the w3wp.exe PID

Write down the PID in the morning and then come back a few times during the day to see if the process is restarting.  When/if the worker process restarts, it will get a new PID.  If you do notice that the worker process is being restarted, consider using the “Generate Recycle Event Log Entry” features available via the Advanced Settings… window for the given application pool.  Figure 2 shows the default settings on a Windows Server 2012 IIS 8 machine.

Figure 2, The Generate Recycle Event Log Entry settings

During the troubleshooting phase you might consider enabling all of the attributes to be certain that you capture as much information as possible.  However, once you complete your troubleshooting phase, consider disabling the ones you do not find useful in
your environment.  The description of these attributes are described in the below bulleted list.

  • Application Pool Configuration Changed – Event is logged when the application pool recycles due to a change in its configuration
  • ISAPI Report Unhealthy – Event is logged because an ISAPI extension has reported itself as unhealthy
  • Manual Recycle – Event is logged when the application pool has been manually recycled
  • Private Memory Limit Exceeded – Event is logged when the application pool recycles after exceeding its private memory limit
  • Regular Time Interval – Event is logged when the application pool recycles on its scheduled interval
  • Request Limit Exceeded – Event is logged when the application pool recycles after exceeding its request limit
  • Specific Time – Event is logged when the application pool recycles at a scheduled time
  • Virtual Memory Limit Exceeded – Event is logged when the application pool recycles after exceeding its virtual memory limits

Once configured, you would begin seeing events logged into the System event logs on the IIS server.  Figure 3 shows 3 logged events which caused a recycle of the application pools’ worker process.

  • Event ID 5186, 5080 and 5079
  • Useful link to IIS Application Pool Recycling event ids

Figure 3, IIS Application Pool Recycling events

The recycling of an application pool is in many cases nothing to be alarmed about.  However, this is a place to analyze and track when you are experiencing some unexpected behavior.  At the same time, if the recycling is happening multiple times throughout the day, you should look into what is causing it to happen as the recycle does have a customer impact.  Read this article which digs deeper into appDomain recycles and the impact they can have here.

via: http://blogs.msdn.com/b/benjaminperkins/archive/2013/07/01/troubleshooting-badly-behaving-iis-application-pools.aspx

IIS 7.5: Avoid performance issues when creating isolated application pools for applications

At NowOnline, we recently experienced major performance problems with two of our webservers (Windows 2008 Web Server with IIS7.5). Over the months memory consumption and CPU usage had increased substantially as the number of hosting packages increased to respectively 290 and 120 websites. As a result, websites running on these machines became progressively slower. Worse, the dreaded ‘Out of memory’ exception started showing up periodically as the servers tried to free and allocate RAM to new worker processes. Adding additional RAM to the virtual machines did remedy the problems for a while, but this was not a permanent solution.

Our hosting provider diagnosed the problem initially and attributed it to the sourcecode and the volume of websites (and suggested adding more RAM). So I set out to figure out what was going wrong, really. I initially explored potential memory leaks or bad code but was unable to find a clear pattern here. Some of the larger sites used more memory, obviously. But I couldn’t find clear examples of the telltale sign of memory leaks; an ever increasing memory consumption by a single website. Next, we started moving websites to another webserver to test if the problem was caused by the load of the increasing pool of websites. Turning off some heavy websites did not improve performance and did not reduce memory load significantly. Any freed up RAM was quickly used up by other websites.

A major part of the solution turned out to be in the way we used application pools. When configuring the webservers I had always adhered to the ‘best practice’ of creating a separate application pool per production site (see this article, for example). This is actually the default behavior when creating a new website in IIS. There are clear advantages to this approach:

  • If a code problem causes the website to crash (i.e. infinite loop or a memory leak), only the associated application pool crashes. This means that other websites are not affected by problems in other websites;
  • This approach makes it easier to tweak application pool settings (CPU and RAM allocation) for specific websites;
  • It is easier to diagnose memory leaks by investigating RAM usage by a single application pool;

IIS is quite clever when it comes to managing the application pools. If a website is not getting any traffic for a while, IIS shuts down the associated application pool by default. This frees up resources (RAM and CPU) for other application pools. Should a new visitor arrive, IIS simply starts up the application pool and spawns worker processes. It soon dawned on me that every application pool requires some overhead in resources. And RAM that was allocated to one pool could not be freely used by another pool.

To test if our configuration (one application pool per website) was indeed causing the problems, I started grouping the websites into several shared application pools based on their logical relatedness and .NET framework. For the more critical websites, I decided to stick to isolated application pools just to be sure. I ended up going from 250 pools to about 20. The results speak for themselves:


Picture 1: Memory consumption by alpha-web1 before and after the change (around 4PM)


Picture 2: Memory consumption by alpha-web2 before and after the change (between 7 and 8.30PM)

The results clearly show that RAM consumption dropped dramatically, from a structural 98% to around 45%. The virtual memory (‘Swap’ in the picture) that had to made available to virtually increase RAM also dropped to zero, which had the nice side effect of lowering Disk I/O. Not only had the servers become significantly more responsive, performance for individual websites also increased.

We initially worried about strange behavior, such as duplicate MVC route names, caching conflicts and such, but experienced none of these. IIS does isolate this kind of behavior nicely.

The lesson that I learned from this is that it’s not a good idea to stick too rigidly to a ‘application pool per website’ practice. Instead, try grouping non-critical websites into shared application pools as much as possible, unless you run into problems. If you have a critical production website, creating a separate application pool is still the best possible advice though. I hope this post will be of help to other administrators struggling with similar performance issues.

via: http://www.christiaanverwijs.nl/post/2013/08/28/IIS-75-Avoid-performance-issues-when-creating-isolated-application-pools-for-applications4.aspx