好的，我们先说几件事。我一开始就是这样配置的，为了达到这一点，我采取了许多（未知的）步骤，首先提高可靠性，其次提高性能。
现在，这两方面我们都遇到了问题。
事实：
- Windows 2003 企业虚拟机（VMWare，我们无权访问 VM 控制台）
- 8 个 CPU（较新的 XEON）
- 16 GB 内存（我认为 12GB 是专用的，其余的是可扩容的）
- 24 GB 页面文件位于其自己的磁盘卷上（所有磁盘都是 SAN，通过光纤连接）
- 尽管一切本质上都是 2.0，但已升级到 .NET 4.0
- 所有内容都是用 C# 在 ASMX Web 服务中编写的
- 这是运行内部开发的应用程序“框架”，以支持连接不佳的用户进行离线数据收集/处理
- 根据“上次同步日期”收集数据并下载到本地 SQL Express 数据库
- 用户可以离线编辑，然后在连接时发送更改
- 除了“框架”应用程序池之外，每个应用程序都有自己的应用程序池
- 我们大约有 1700 名用户分布在各个应用程序中，其中许多用户拥有多个应用程序。
- 大约 400 名“重度”用户使用多个应用程序
- “框架”应用程序池有 1 个工作进程，App 1、App 2 和 App 3 均有 10 个工作进程。
- 应用 4 到 6 有 1 个工作进程
- App 1 是一个 24x7x365 应用程序，它必须始终运行。
- 应用 1-3 配置为每 240 分钟回收一次
- 根据趋势数据，我们发现，如果我们在一小时内维持超过 80-90 次“同步”，就会出现大量超时问题。
- 看起来很多工作进程什么都没做
- 我觉得我们可以将每个应用程序池减少到大约 4 个 WP
- 早期有很多进程锁定问题。不确定 10 个 WP 是否合理，只是他们选择了这个，而且它工作了相当长一段时间
- 应用程序 1 在高峰时段（每小时同步 50 多次）将迅速占用约 5.5 GB 的内存。
- 随着事情的进展，最终一些用户会收到“超时”错误
- 我宁愿看到该应用程序池中有 3 个进程，每个进程占用 2.5 GB（临时），而不是一个进程独占所有内存。
- 这表明只有一个进程正在处理请求。
- 我们尝试根据内存限制等情况更频繁地进行回收。我们得到了更多以下错误：
- System.IO.IOException：无法从传输连接读取数据：远程主机强制关闭现有连接。
- 今年，我们已经禁用 App 1 的应用程序池大约 3 次（由于快速失败保护？），而 App 2 也发生过一次这种情况。
我们需要做的是控制整个混乱局面，更好地利用我们拥有的资源，如果可能的话，尽快改善这个应用程序的平衡。
理想情况下，我认为我们需要转向具有适当负载平衡器和 ASP.NET 状态服务器的多服务器环境。不过，我们现在确实可以访问可以使用的状态服务器，因此，如果在工作进程中使用该服务器有任何好处，我们就可以这样做。还想提一下，添加服务器（即使是虚拟服务器）不是一个快速的过程（新 VM 至少需要 6 周才能完成），而且公司正在评估迁移到新数据中心，因此他们会抵制设置任何新东西，尤其是物理系统。
我们确实拥有服务器的管理员权限，除了重启服务器之外，我们作为开发人员/架构师可以做任何需要做的事情。我们必须获得特殊许可/通知服务器监控团队有关重启的信息。
我承认这开始超出了我的知识范围，我们需要一些指导。请提出尽可能多的问题，以便更好地了解我们正在做的事情。任何最佳实践或一般建议也很有用。
如果需要的话，我还可以提供有关网络服务之间的通信等的更多详细信息。
编辑1：我应该解释一下通用的“同步”。用户 A 连接到框架服务器进行身份验证/日志记录。然后根据需要连接到每个应用程序 Web 服务。数据从一系列来源（第三方 WS、Oracle 和 SQL 数据库、文件共享等）收集，然后使用数据集传递给客户端。每次同步都有各种步骤（每次调用应用服务来完成工作，并调用框架服务进行日志记录），每个步骤对于应用程序来说都是唯一的。
答案1
听起来，可扩展性问题出在应用服务器而不是数据库服务器上。因此，最好的办法是对应用服务器进行负载平衡。
负载平衡非常简单，可以在网络级别完成。这允许您将 X 个物理机或虚拟机放在 VIP 后面，并单方面将负载分配到机器上。给定用户的每个请求将命中不同的机器。
在进行负载平衡时，最好避免使用会话状态信息。但是，如果无法避免，则需要所有计算机都可以连接的会话状态服务器。这在 .NET 中相当简单，因为可以使用 Web.config 轻松插入会话状态提供程序。这允许应用程序服务器本身无状态，因此 VIP 可以将传入流量定向到它想要的任何服务器。
如果某台机器出现问题或需要维护，负载平衡还允许您将其停用。这在部署期间也很有用，因为您可以让一半的机器停用并进行部署，然后交换它们。这可以防止同时运行两个版本的应用程序代码。