MOSS Web application configuration notes for a medium farm - from the field

I attended another UK SPSUG usergroup meeting last night at the new Microsoft building near Victoria Station in London. There were interesting presentations on MOSS architecture and some of the more varied tasks you can use Sharepoint designer for.

Hardware Topology

We have configured a medium farm using 6 x 64-bit HP servers with 8GB RAM. 2 load balanced Front End web servers also running query, an application server running index and an application server running forms and excel services. The second application server also runs web so that the index server can hit it directly without impacting on the users FE servers. The SQL backend servers are clustered in an Active-Active configuration using an HP SAN for storage.

With all of this hardware and horsepower you would have thought that things would run very well, however we have been having large IIS issues. These seem to have come from some of our design decisions which were taken for the right reason at the time, but in retrospect need significant tuning.

The importance of design and planning

We spent a lot of time deciding to split out our Departments (Services), Offices, Industry Sectors, Mysite the SSP and other published extranets into separate Web applications each with their own site and site collections. This would mean that each part would be isolated and resilient and addressable using discrete DNS paths, such as http://services.company.com/ . We took this idea further in the design by creating web applications for each of the individual services ie http://it.company.com/ .

We rolled this model out and found that it was a disaster. Performance was awful and memory usage sky rocketed. Subsequently we consolidated the Web Applications down to about 8. This helped significantly with the memory and performance but we were concerned that after all our careful planning we had arrived at a compromise solution by fire fighting and not science.

SPSUG discussion on Web application design

The first thing to note is that by default an IIS worker-process within a web application will consume up to 1Gb RAM. You can modify this figure so that the worker-process re-cycles after a defined memory limit is hit, however whilst it is re-cycling your users cant access the site.

Web gardens

A recommendation to solve this problem (from an IIS environment generally rather than MOSS in particular) is to setup 2 or 3 worker-processes within each web application. Configure them to re-cycle at around 500Mb. This has the benefit of users not loosing connection whilst one of the worker processes is re-cycling and actively controlling the refresh and memory usage of each worker process. (Be careful not to set the memory re-cycling limits too low as there is the possible down side when the first worker process re-cycles the second and third have to takeup the load from the users. This increases the memory usage of the second and third worker processes which may then have to re-cycle in turn causing a cyclical spiral of constantly re-cycling worker processes!) . You should not set more than 4 worker processes per web application.

How many web applications and how do you apply them ?

So now we can control the memory for the web applications, where is the most appropriate place to use separate web applications?

From the discussions at the usergroup it would appear that best practice is to initially setup separate web applications for:

1. The SPS (obviously as this is only used for administration it only needs one small worker process)
   
2. MySite
   
3. Portal Site
   

After that the decision on additional web applications seems to be based on

1. The isolation required between Sites
   

   If a high isolation level is required then separate web applications should be produced
   

   
   

2. The planned activity within a Site
   

   Sites which have dynamic and frequently changing content should be in separate web applications to those that provide mostly static content. Again a more aggressive web garden strategy should be applied to the dynamic site, whereas more object caching should be enabled for the static sites.
   

   
   

32bit vs 64bit

At the user group there was a discussion about using 64bit processors. With the extra memory and addressing capabilities a medium farm with 64bit servers throughout gains a 40% increase in performance over a 32 bit solution. It was also noted that Microsoft dont support a mixed hardware farm of 32 and 64bit machines. They say you should not do this and it will cause problems.