Page ghosting is an optimization used with site pages in which a single page template can be used to process multiple page instances across many different sites. For example, the home page for every team site in a WSS farm is based on an underlying page template named default.aspx that resides on the file system of the front-end web server. A page template is complied into an assembly DLL and loaded into memory just once per web application. However, this page template and its efficent useage of memory can still be used to server up pages for thousands of sites. This an obvious advantage toward scalability.
When a user costomizes a site page by using the SharePoint Designer and then save those changes, a customized version of the page definition is stored in the content database. While this provide flexibility form a customization standpoint, it also can have negative impact on performance and scalability. When the customized page is requested, its page definition must be retrieved from the backend database server by the SPVirtualProvider component and then fed to the ASP.NET compiler, where is parsed and loaded into memory. You can imagine that a web application with thousands of customization pages requireds more memory becaused each customized page definition must be serperately parsed and loaded into memory within the application pool that is hosting the current web application.
You should note that customized pages are not processed by using the standard ADP.NET in which a page is compiled into an assembly DLL. Instead, customzied pages are parsed by the ASP.NET page parser and then processed using the no-compiled mode feature that was introduced with ASP.NET 2.0
As a developer, your initial reaction to this might be to question why customized pages are processed in no-compile mode. Your instincts likely tell you that compiled pages run faster than no-compile pages. However, no-compile pages can be more efficient and more scalable in certain scenarios. This is especially true in a large WSS environment where the number of customized pages can reach into the thousands or tens of thousands.
No-compile pages can be loaded into memory and then unloaded in a manner that is not possible for compiled pages because the .NET Framework doesn’t really support the concept of unloading an assembly DLL from memory. The closest equivalent would be to recycle the current Windows process or the current .NET AppDomain. However, this type of recycling involves unloading all assembly DLLs from memory, not just those assembly DLLs that haven’t been used recently. Furthermore, the .NET Framework places an upper limit on the number of assembly DLLs that can be loaded into a .NET AppDomain.
No-compile pages provide higher levels of scalability because they do not require loading new assembly DLLs or managed classes into memory. Instead, the processing of no-compile pages involves loading control trees into memory. WSS can manage the memory usage for the control trees associated with customized pages more efficiently because they are not compiled into assembly DLLs. For example, once WSS has finished processing a customized page, it can unload the page’s control tree to free up memory for other purposes. Furthermore, nocompile pages eliminate the need to go through the compilation process, which actually provides faster response times for pages upon first access.