好的，我们现在陷入了困境，非常希望能得到SO社区的反馈。
我们的基本问题是MOSS基础架构下的内部网站性能缓慢--
一些环境信息：
我们拥有一个用于协作的MOSS标准版网站。
一般症状：加载主页和已经“预热”的页面相当迅速，但是偏离主流路径的页面/站点加载非常缓慢。
我们看到有时页面突然需要30秒才能加载完成，而正常情况下只需要2秒。
我们已经采取的措施如下：
我不知道还能做什么——将其分成多个站点集合？
切换到64位前端服务器？
非常希望能听到其他类似情况的人的经验分享。
您没有说明前端服务器有多少内存 - 鉴于它们是32位的，我将假定每个工作进程的最大内存约为2GB+。
我的建议？切换到64位，增加更多的内存，并检查您是否仅在每个前端使用一个w3wp工作进程。深入研究“Web Gardens”，也就是配置多个w3wp进程的前端。首先，每个前端使用两个workerprocesses，看看效果如何。还要确保它们设置了回收，并且每对工作进程的回收不重叠 - 有两个或以上的工作者意味着他们可以轮流回收而不会中断访问。
这只是我的建议。
-Oisin
数据库服务器是否在单独的服务器上还是在您的 Web 服务器之一上？
您是否在前端或数据库服务器上看到 CPU/磁盘瓶颈？
听起来您是全球性的；您是否从接近服务器的网络中看到相同的性能问题 - 这是否是 WAN 问题？
是的，缓存是减轻系统负载的最佳方法。为 SQL 服务器添加 RAM 也很好。(64 位对于 SQL 服务器来说真的是必须的，WFE 不太重要)。
不确定您是否想要回收进程。我没有证据支持这一点，只是和某人交谈时得知回收进程似乎解决了一个性能问题，但引入了其他问题。
我提到过缓存吗？
SQL 服务器应该处理高达 100GB 的数据库，但在这种大小下，备份等方面将很难管理，因此将您的站点分成相关的站点集可能是您现在需要计划的事情，但这可能与性能无关。
你看过软件边界计划（Office SharePoint Server）了吗？
乍一看，你的服务器符合他们推荐的设置。
为了提高性能，你应该看看：
}}我运行的设置非常相似，但是我们有超过400GB分布在3个站点集合中。在走向64位路径之前，还有一些其他尝试的方法。
希望这可以帮助！
我建议也采用64位。也许不是立即解决问题的方法，但从长远来看，我会把转向64位作为整个系统的目标。
我对Nat的评论也有些异议，认为这在Web前端并不重要。我不会争论基准测试或争论内存可寻址性。事实上比这更简单。
微软已经公开表示，2007年是SharePoint最后一个可以在32位服务器上运行的版本。未来将需要64位 - 就像FRAM油滤器的广告语一样 - “现在付款还是以后付款”...
一定要检查磁盘使用情况。如果您有两个虚拟机并且它们运行在同一个磁盘/ SAN 上，请确保它没有过于繁忙。过载的 SAN 会影响性能。
我们也遇到了性能问题。我们升级到Win 2008 64位，这带来了一些变化，但并不如预期的那么多。
从NTLM认证转换为Kerberos给我们带来了很大的提升。这是我们最主要的改进。
希望对某些人有所帮助。
.gif){kind=link}