aspnet常用的26个优化性能方法(编辑修改稿)

aspnet常用的26个优化性能方法(编辑修改稿)内容摘要：

件的性能开销使得将组件迁移到托管代码是值得的。 每一情况都是 不一样的，决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。 建议您研究一下如何将需要大量调用以进行交互的任何 COM 组件迁移到托管代码。 许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。 在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。 因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个 大调用而不是一系列小调用。 例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。 另外，一处理完任何 COM 对象或本机资源就释放它们。 这样， 其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。 12. 在 Visual Basic .NET 或 JScript. 代码中使用早期绑定 以往，开发人员喜欢使用 Visual Basic、 VBScript. 和 JScript. 的原因之一就是它们所谓 “ 无类型 ” 的性质。 变量不需要显式类型声明，并能够简单地通过使用来创建它们。 当从一个类型到另一个类型进行分配时，转换将自动执 行。 不过，这种便利会大大损害应用程序的性能。 Visual Basic 现在 通过使用 Option Strict 编译器指令来支持类型安全编程。 为了向后兼容，默认情况下， 不启用该选项。 但是，为了得到最佳性能，强烈建议在页中启用该选项。 若要启用 Option Strict，请将 Strict 属性包括在 @ Page 指令中，或者，对于用户控件，请将该属性包括在 @ Control 指令中。 下面的示例演示了如何设置该属性，并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。 %@ Page Language=VB Strict=true % % Dim B Dim C As String 39。 This will cause a piler error. A = Hello 39。 This will cause a piler error. B = World 39。 This will not cause a piler error. C = !!!!!! 39。 But this will cause a piler error. C = 0 % Dim B Dim C As String 39。 This will cause a piler error. A = Hello 39。 This will cause a piler error. B = World 39。 This will not cause a piler error. C = !!!!!! 39。 But this will cause a piler error. C = 0 % JScript. .NET 也支持无类型编程，但它不 提供强制早期绑定的编译器指令。 若发生下面任何一种情况，则变量是晚期绑定的：被显式声明为 Object，是无类型声明的类的字段，是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。 最后一个差别比较复杂，因为如果 JScript. .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。 在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。 var A。 var B。 A = Hello。 B = World。 B = 0。 为了获得 最佳的性能，当声明 JScript. .NET 变量时，请为其分配一个类型。 例如， var A : String。 13. 使请求管线内的所有模块尽可能高效 请求管线内的所有模块在每次请求中都有机会被运行。 因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。 分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。 14. 使用 方法在同一应用程序的页面间重定向 采用 语法，在页面中使用该方法可避免不必要的客户端重定向。 15. 必要时调整应用程序每个辅助进程的线程数 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。 已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。 这项技术称作线程门控。 但是在某些条件下，线程门控算法不是很有效。 通过使用与 Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。 当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。 如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。 遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。 通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源， 对 Web 服务器的吞吐量并无帮助。 为缓和这种情况，可以通过更改 配置文件节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。 注意：辅助线程是。