Creating a SharePoint web application requires many configuration settings, and some are difficult to change once the application has been created. Thus, it’s important to highlight some of the key architectural components that make up a SharePoint web application prior to creation. Understanding these components will ensure you have the knowledge to effectively create and manage your SharePoint web applications. This section covers the major components found within a SharePoint web application and briefly discusses how they work within IIS.
Working with SharePoint Web Application Components
Logically, a SharePoint web application holds multiple site collections. In fact, that’s the purpose of a SharePoint web application: to provide a URL where site collections can be mounted. Before we go too much further, it helps to have a basic grasp of site collections and how they are stored on disk. More details on site collections are covered in Chapter 3, “Creating and Managing Site Collections.”
Exploring Site Collection Basics
A site collection is a collection of SharePoint websites organized in a hierarchy, just like folders. Many SharePoint artifacts and configuration settings are shared throughout a site collection. Some of these artifacts include master pages, content types, web parts, templates, and, perhaps most importantly, security. Each site collection has a single top-level or root website, which is where these shared artifacts are stored. Websites also contain lists and libraries where user content such as tasks, calendar entries, and documents are found. While SharePoint can support thousands of site collections per web application, most use a much smaller number.
Working with Content Databases
Content databases are stored in SQL Server and hold all the content and metadata associated with site collections. When you create a new web application, a new content database is also created. A site collection is created within a web application. When a site collection is created, it is stored within one of the web application’s content databases. Here are some key rules to remember when working with content databases:
- A site collection cannot be spread across multiple content databases.
- A content database is associated with just one web application.
- A web application can have multiple content databases.
- A content database cannot be spread across separate web applications.
- Content databases should be kept as small as possible—in general, do not exceed 200 GB for each one.
Figure 2.1 depicts the relationship between SharePoint web applications, content databases, and site collections.
Figure 2.1: Relationship between web applications, content databases, and site collections
NOTE SharePoint 2010 also allows you to store content outside of the content database, in the file system. This is done by configuring Remote BLOB Storage (RBS) for a particular content database. RBS is commonly used when you have very large content databases (more than 500 GB) and need to use a cheaper form of storage. With RBS, only the files stored in lists and libraries (the files are the BLOBs, or Binary Large Objects) within SharePoint websites are stored in the file system. All other content and metadata is still stored in the content database and the rules associated with content databases and site collections (including quotas) still apply. To learn more about RBS and how to install and configure it, see the article “Install and Configure Remote BLOB Storage (RBS) with the FILESTREAM Provider (SharePoint Foundation 2010)” at http://technet.microsoft.com/en-us/library/ee663474.aspx.
How SharePoint Web Applications Work
Internally, SharePoint web applications are complex ASP.NET web applications. Fortunately, knowing all the details about the inner workings is not important. This section focuses on just the essentials.
Understanding SharePoint’s Relationship with IIS
At a basic level, a SharePoint web application is an IIS-configured web site. It consists of IIS properties such as authentication type, application pool, and binding details such as host header (i.e., the URL), IP address, and TCP port. As you will learn shortly, most of these settings are configured from SharePoint—SharePoint administrators do not regularly go into IIS to adjust these settings.
When a SharePoint web application is created, a new IIS website is created on each web front end (WFE) server along with a few files and subfolders located at C:inetpubwwwrootwssVirtualDirectories<host header & port>. In this folder, a very important file named web.config exists. This is an ASP.NET configuration file that configures the IIS website to be a SharePoint web application. There are occasions where you need to manually modify this file (covered elsewhere in this book).
NOTE Understanding terminology in SharePoint is tricky. In particular, the word site is a troublesome as it means different things in different contexts. For example, you have IIS websites, SharePoint site collections, and SharePoint websites. An IIS website is completely different from a SharePoint website. What you need to remember is that an IIS website is associated with a SharePoint web application.
Using Application Pools
An application pool is used by IIS to process and execute requests that are received by the WFE server. It is associated with the IIS website and SharePoint web application.
You must specify which application pool to use when creating a new SharePoint web application. You have the option of creating a new application pool or sharing (reusing) an existing one. From a security standpoint, it’s best to have separate application pools for each web application. However, this approach does consume more RAM on the WFE servers, which affects performance, especially if you have limited memory.
An application pool gobbles up memory quickly because it can be very active. It also does a great deal of caching. For production environments, this amount can vary widely but usually falls between 200 MB and 8 GB. Due to the large amount of RAM used by the cache, it is essential to ensure your WFE servers have sufficient RAM to avoid excessive paging (using disk when RAM is unavailable). Microsoft recommends having no more than 10 application pools per farm, but this is not a hard limit.
NOTE Technically, an application pool is a Windows process named w3wp.exe and is often called the worker process. As with any Windows process, it requires an associated user account. The account associated with w3wp.exe is called the application pool identity.