IIS Insider - June 2001
Top 5 Questions and Answers on Internet Information Services
Determining Hardware Upgrade after Upgrading to IIS 5.0
Q: We have plans to significantly increase our Web site traffic. To assist with the additional load, we are planning to upgrade to Microsoft® Internet Information Services (IIS) 5.0. How can we determine if we should also upgrade our hardware?
A: This is a very good question. There is no standard answer, as each installation has a different set of requirements and comes into the upgrade with a different set of circumstances. There are many factors to consider. Among them is the kind of content your site is serving — static or dynamic. Believe it or not, most sites are just a few HTML pages that don't change very often. If this is your situation, the first bottleneck you will encounter will be your network or disk drive. In other words, IIS 5.0 can server a boatload of static pages very quickly. A single CPU 200 MHz Pentium Pro with 512 megabytes (MB) of RAM can server about 1109 static pages that are approximately 8 kilobytes (KB) each, per second (IIS Resource Guide, Chapter 4 page 148). A modest server will make an excellent Web server for this kind of content.
Of course, delivering static pages is the best case scenario for IIS. Running Active Server Pages (ASP), Perl, or any Web-based application requires more from your server. Many other factors, including the use of Secure Sockets Layer (SSL), databases, available network bandwidth, and the type of authentication method that you will use, will also impact performance.
Since there are so many variables, all methods of estimation are basically just that — estimations. While it can be useful to estimate potential resources required for a load, it is strongly recommended that a proposed production server be tested with a simulated load before being placed online. This can reveal bottlenecks in unexpected places. For example, you may find that you have a third part or custom COM+ object in your Web application that works when traffic is under a certain threshold, but cannot scale to meet the demands of an increased load. In this situation, adding more powerful hardware makes matters worse as it increases the capacity of the system to load the object with requests. This is the kind of circumstance you want to identify well in advance of placing your system online.
There is a chapter about estimating your server's capacity in the IIS 5.0 Resource Guide — Chapter 4 "Capacity Planning". The IIS Resource Guide is part of the Microsoft Windows® 2000 Server Resource Kit and is not available separately. For more information, see:
- Deploying Windows 2000 with IIS 5.0 for Dot Coms: Best Practices
- Web Performance Tuning by O'Reilly & Associates, Inc.
Web site Limit with IIS 4.0 and IIS 5.0
Q: What are the limits on the number of Web sites that you can have with IIS 4.0 and IIS 5.0?
A: Neither IIS 4.0 nor IIS 5.0 have built-in limits regarding the number of Web sites that you can have. You won't add a Web site and see a message like "You have reached the maximum number of Web sites allowed". Think of it like this— your Web server represents a pool of available resources. How you allocate those resources is up to you, but at some point you will have allocated all you can and a have reasonable response from the server. That allocation may be one huge Web site with thousands of directories and 1068465904supporting e-commerce portal1068465904, or hundreds or perhaps thousands of smaller Web sites that don't have as much content. This last scenario is the most common for an Internet Service Provider (ISP) or Web hosting service.
One of the biggest factors in how many sites can effectively be supported is the decision to run applications in process or out-of-process. In process applications run in the Inetinfo process and are best for performance but should an application fail, the Web server will stop serving pages. Out-of-process applications create greater stability in that a failed application will not stop the Webs server, but this comes with a performance penalty and the cost of consuming additional resources. IIS 5.0 Documentation states, "you should not run more than 10 isolated applications." 1068465905I would say1068465905 that 10 is too conservative a number, but the point is well taken. Also, keep in mind that with IIS 5.0, we are talking the about "High (Isolated)" application protection setting here and not "Medium (Pooled)".
In very general terms, the perceived limit, meaning, if you asked a few hundred IIS Administrators what they found the limit to be, and combined that with Microsoft testing, you could venture a reasonable but general estimation that the perceived limit for IIS 4.0 is approximately 250 and for IIS 5.0, it's 10-15 times that (see Performance of Internet Information Services 5.0: The Internet Services Provider Scenario at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/deploy/projplan/ispscen.mspx). For IIS 6 expect another quantum leap.
Another option for ISPs that have a large number of sites with static content, Microsoft's Scalable Hosting Solution Overview at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/downloads/shsover.mspx offers a way to host many thousands of Web sites while using only one actual virtual Web site in IIS.
Is FTP Domain Authentication Required?
Q: We are using the IIS 4.0 FTP server so that users can upload files. The FTP server is a Microsoft Windows NT® 4 member server and is a member of the our domain. When users access the FTP server, they have provide their name as "Domain/Username" in order to gain access. Is there some way to setup the FTP server so this is not required?
A: As you have discovered, by default, the FTP service will use the local user account database for authentication. In order to provide a "domain" logon, users are required to enter "domain/username". In IIS 4.0, you can set the default domain according to the instructions found in "Setting up FTP Domain Authentication in IIS 4.0". In IIS 5.0, this setting can be configured in the user interface.
Error Writing Encrypted Data to the Web Servers Configuration Database
Q: We are trying to install IIS 5.0 and are receiving the message "error writing encrypted data to the Web servers configuration database". We've uninstalled IIS to try again, but every time we keep getting this message whenever we try to install IIS 5.0.
A: This particular problem can occur during an installation or reinstallation of IIS 5.0. You may find yourself in this situation when you install Windows 2000 and due to some difficulty encountered during the installation, IIS does not start. Reinstallations may be necessary if a problem is caused by a problem that occurred during the initial installation of Windows 2000, where IIS 5.0 is installed by default or IIS 4.0 is upgraded to IIS 5.0. You can fix the problem as follows:
Remove IIS
Use Windows Explorer to navigate to the:
%Windir%\Profiles\All Users\Application Data\Microsoft\Crypto\Rsa\MachineKeys directory.
Rename the Machinekeys folder to Machinekeys1
Reinstall IIS.
If all goes well, and it should, delete the Machinekeys1 folder. You can find additional information on this problem and solution in KB article Q282775.
Performance Penalty Using Host Headers Feature?
Q: We just installed IIS 4.0 and are trying to determine if it's best to use an IP address for each site, or use the Host Headers feature with all Web sites using the same address. Is there a performance penalty? What other issues are involved?
A: Using the Host Headers feature, you can set up IIS a Web site to respond to one or many domain names. In this way, you can have multiple Web sites using the same IP address. You can find a tutorial on how to implement this at https://www.iisanswers.com.
There are, however, some considerations that may not be immediately obvious. One of the most common questions regards the impact on performance that results from using Host Headers. The good news is that while there is an impact, it's hard to detect. If you choose to avoid the use of host headers, it should be for reasons other than performance.
Another potential objection is that a browser must be HTTP 1.1 compliant to be compatible with an IIS server using host headers. This is true, but if HTTP 1.0 compatibility is really a design goal for your site, you are basically serving static pages with no frames, scripting, Extensible Markup Language (XML), Cascading Style Sheets — the list goes on and on. It is like designing for a black and white monitor. In other words, there comes a time when the cost of carrying forward legacy capabilities (or the lack thereof) outweighs the benefits.
There are other more significant considerations. in the IP versus Host Header decision. You cannot use SSL with a site identified by Host Headers. A common misconception is that this is a limitation of IIS, but this is not so — it's just that the two technologies have irreconcilable differences.
In brief, when the HTTP packet arrives to the IIS server in an SSL exchange, it is encrypted. The HTTP packet contains the host header name, but since it's encrypted IIS can't decode the packet without first establishing an SSL session. However, to start an SSL session, IIS has to know which Web site is requested. So, it's a Catch-22. KB article Q187504, IIS: HTTP 1.1 Host Headers Not Supported When Using SSL addresses this issue. While it refers only to IIS 4.0, this article applies to IIS 5.0 as well.
There is another reason why you may want to use an IP address to identify your Web sites. Some search engines are IP address sensitive and limit the number of entries they will index for a single IP address. See https://www.promotionbase.com/article.php?aid=264&pid;=0 and https://www.onlinewebtraining.com/. If your IIS server is serving content on the Internet, you may want to consider.
Finally, there is an issue related to IIS 5.0 socket pooling. Socket pooling is one of the reasons IIS 5.0 scales better than IIS 4.0. It allows the server to share resources dedicated to an IP address and TCP port with other Web servers using the same port. See Internet Information Services 5.0 Technical Overview, at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/deploy/depovg/iis5tech.mspx. By default, all Web sites on IIS 5.0 have socket pooling enabled. This means that if you tune a Web site using the Performance tuning slider on the performance tab, all Web sites in the pool will be adjusted. Normally, you don't need to tune Web sites, but in the event that you have one very active site and other sites with low use, .the low use sites use resources that you need for the high use site. It makes sense in this scenario to tune the high use site using the performance tab for high traffic and low use sites for low traffic. To do this, you must remove the high use site from the socket pool as per the instructions in Q238131. So what does all of this have to do with host headers? A host header site can't be removed from the pool individually, so it cannot be independently tuned in this way.
Host headers are extremely convenient, perform well, and are easy to implement. They solve the problem of a huge demand for Internet accessible Web sites and a shrinking supply of IP addresses to serve them. In fact ARIN, which issues IP addresses, is making policy changes, including that the use of Host Headers is a best practice. There are a few considerations you should know about, but you will generally find that using Host Headers is an easy choice.
Submit your questions for the IIS Insider. We will post these questions along with the answers in a future IIS Insider column.
For a list of previous months questions and answers on IIS Insider columns, click here.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.