当横向可伸缩性较为合适之后，继续追求从您的计算机开始的纵向可伸缩性。 忽视了防火墙的考虑（帮自己一个忙。如果计算机间的产品环境有防火墙，则在测试方案中添加防火墙。） 将引用 ASP 内置对象的组件置于与 IIS 服务器分离的计算机上（回调和编组 ASP 内置对象的成本很高。） 使用组件内部的后期绑定（这产生对 GetIdsOfNames 的额外调用，这在分布式应用程序中可能很昂贵。尽量使用早期绑定。） 按引用传递参数（这产生更多的编组开销。尽可能“按值”传递参数。） 成功地从 IIS 调用远程 MTS 组件也可能很棘手。一个简单有效、既提高性能又简化安全性问题的解决方案，是调用中间的 MTS/COM+ 软件包/应用程序。早期绑定可减少网络路程段，提高性能。如果您使用“服务器”软件包/应用程序，则可以设置软件包/应用程序的运行标识。这个技术将在 KB 文章 159311 Instantiating Remote Components in Microsoft Transaction Server and Internet Information Server 中讨论。
详细信息 如果已经解耦了服务，特别是已使 ASP 在业务组件之外，则分布将相当灵活。您就可以更多地考虑框围，并根据需要分散组件以解决随之而来的可伸缩性和性能问题。如何知道？进行测试。如何测试？请看下面的基本指南：
若要测试 Web 站点的可靠性，请剖析计算机并检查错误。 若要测试性能，请查看每秒可处理多少 ASP 请求。 若要测试可伸缩性，请设置每秒需要处理多少 ASP 请求的阀值。用重要的工具考验应用程序——添加用户直到性能坏到不能接受为止。 加强对应用程序的测试非常重要，因为需要暴露运转条件和单浏览器测试中不会出现的其他问题。 有关对应用程序加强测试的详细内容， 请参阅 I Can't Stress It Enough -- Load Test Your ASP Application（英文）。
结论 正如所见，有一些事情在整个开发中需要时刻注意。在此，应用程序指南所涉及的诸多因素已全部阐明，因为它们有助于彻底避免严重失误。在整个开发周期中遵循本文中略述的几个指南，不仅可以避免一些额外的工作，而且能够提交可收缩的、可靠的、高性能的基于 ASP 组件的解决方案。
精品推荐