ASP 包含一种非常快捷的创建 HTML 代码的方法，只需多次调用 Response.Write。Write 函数使用隐式优化的字符串缓冲区，此缓冲区能够提供非常优秀的性能特性。修改后的 WriteHTML 代码如下所示：
| Function WriteHTML( Data ) Dim nRep For nRep = 0 to 99 Response.Write "<TR><TD>" Response.Write (nRep + 1) Response.Write "</TD><TD>" Response.Write Data( 0, nRep ) Response.Write "</TD><TD>" Response.Write Data( 1, nRep ) Response.Write "</TD><TD>" Response.Write Data( 2, nRep ) Response.Write "</TD><TD>" Response.Write Data( 3, nRep ) Response.Write "</TD><TD>" Response.Write Data( 4, nRep ) Response.Write "</TD><TD>" Response.Write Data( 5, nRep ) Response.Write "</TD></TR>" Next End Function |
虽然这段代码很可能为我们提供最佳的性能和可缩放性，但在某种程度上已经破坏了封装，因为现在会将函数内部的代码直接写入 Response 流，所以调用代码丧失了一定程度的控制权。另外，移动此代码（例如，移入 COM 组件）将变得更加困难，因为此函数与 Response 流存在依赖关系。
测试上面提到的四种方法分别通过一个简单的 ASP 页面（包含一个由虚拟字符串数组提供数据的单个表格）进行了测试。我们使用 Application Center Test? (ACT) 从单个客户端（Windows? XP Professional，PIII-850MHz，512MB RAM）针对 100Mb/sec 网络中的单个服务器（Windows 2000 Advanced Server，双 PIII-1000MHz，256MB RAM）执行了测试。ACT 配置为使用 5 个线程，以模拟 5 个用户连接至网站时的负载。每个测试都包括 20 秒预热时间和随后的 100 秒负载时间，在负载期间创建了尽可能多的请求。通过更改主表格循环中的重复次数，针对不同数目的连接操作重复运行测试，如 WriteHTML 函数中的代码片断所示。运行的每个测试都使用上文提到的四种不同的方法执行。
结果下面的一系列图表显示了各种方法对整个应用程序吞吐量的影响，以及 ASP 页面的响应时间。通过这些图表，我们可以了解应用程序支持的请求数目，以及用户等待页面下载至浏览器所需的时间。
表 1：使用的连接方法缩写的说明
| 方法缩写 | 说明 |
|---|---|
| RESP | 内置 Response.Write 方法 |
| CAT | 标准连接（“&”）方法 |
| PCAT | 加括号的连接（“&”）方法 |
| BLDR | StringBuilder 方法 |
在模拟典型 ASP 应用程序工作负荷方面，此测试与实际情况相差甚远，从表 2 中可以明显看到，即使重复 420 次，此页面仍不是特别大。现在很多复杂的 ASP 页面在这些数字上都是比较高的，设置有可能超出此测试范围的限制。
表 2：测试示例的页面大小和连接数目
| 重复次数 | 连接数目 | 页面大小（以字节为单位） |
| 15 | 240 | 2,667 |
| 30 | 480 | 4,917 |
| 45 | 720 | 7,167 |
| 60 | 960 | 9,417 |
| 75 | 1,200 | 11,667 |
| 120 | 1,920 | 18,539 |
| 180 | 2,880 | 27,899 |
| 240 | 3,840 | 37,259 |
| 300 | 4,800 | 46,619 |
| 360 | 5,760 | 55,979 |
| 420 | 6,720 | 62,219 |
图 2：吞吐量结果图
从图 2 的图表中可以看到，正如我们所预期的，多重 Response.Write 方法 (RESP) 在测试的整个重复测试范围中为我们提供了最佳的吞吐量。但令人惊讶的是，标准字符串连接方法 (CAT) 的下降如此巨大，而加括号的方法 (PCAT) 在重复执行 300 多次时性能依旧要好很多。在大约重复 220 次之处，字符串缓存带来的性能提高超过了 StringBuilder 方法 (BLDR) 固有的开销，在这一点以上，在此 ASP 页面中使用 StringBuilder 所需的额外开销是值得的。
图 3：响应时间结果图
图 4：省略 CAT 的响应时间结果图
图 3 和图 4 中的图表显示了按“到第一字节的时间”测量的响应时间（以毫秒为单位）。因为标准字符串连接方法 (CAT) 的响应时间增加过快，所以又提供了未包括此方法的图表（图 4），以便分析其他方法之间的差异。有一点值得注意，多重 Response.Write 方法 (RESP) 和 StringBuilder 方法 (BLDR) 随重复次数的增加呈现一种近似线性的增长，而标准连接方法 (CAT) 和加括号的方法 (PCAT) 则在超过一定的阈值之后开始迅速增加。
小结本文着重讲述了如何在 ASP 环境中应用不同的字符串构建技术，这些内容同样适用于所有使用 Visual Basic 代码创建大型字符串的方案，例如手动创建 XML 文档。以下原则可以帮助您确定哪种方法最适合您的需要。
尽管您可能未看到本文所示的这种性能增长，但我已在真实的 ASP Web 应用程序中使用了这些技巧，只需要很少的额外投入就可以在性能和可缩放性方面获得很大的提高。
我来说两句：
推荐文章
相关文章