I have recently spent a lot of time working with Microsoft Office SharePoint Server (MOSS) 2007 and Excel Services. I can honestly say that MOSS is much easier to work with and much more feature rich than it's predecessor, but there is certainly a lot to think about with respect to capacity planning.
In my current project I am working exclusively with the Business Intelligence aspects of SharePoint and am relying on SharePoints capability to deploy dashboards and KPI lists that use a combination of Excel workbooks and SSRS reports that use connections to SSAS cubes. It turns out that Excel Services requires a fair amount of processing power, which, coupled with the base requirements for MOSS, means that we require significant hardware to deploy the solution even for a small number of users. The following diagram represents the logical layout of our single server deployment:
According to Microsoft, this configuration is not recommended for a production system. I can certainly see why, given the performance requirements.
One thing that we have run across on a regular basis is that MOSS tends to really fragment memory, and even on systems with a fair amount of available memory, SharePoint and Excel Services tend to require contiguous blocks of memory, which can quickly become constrained if access to Excel Services is requested by more than a one user. In order to alleviate this problem, the HeapDeCommitFreeBlockThreshold registry setting (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager) needs to be changed to 0x00040000 in order to ensure that the garbage collector keeps up with memory requests.
Fortunately for us, Microsoft has realized that MOSS performance and scalability is a concern for many organizations and have begun to publish very good information on MOSS deployment. I just wish that Microsoft Learning would realize that they need to publish some good MOSS deployment courses.
Take a look at the TechNet article on SharePoint capacity planning.