[ASP] 改进ASP应用程序中的字符串处理性能 应用程序, 检查, function, 字符串, 缓冲区

此类中使用的基本原则是，在类级别将变量 （m_stext） 用作字符串缓冲区，并使用 space$ 函数以空格字符填充此缓冲区以将其设置为特定的大小。如果要将更多文本与现有文本连接在一起，则在检查缓冲区的大小足以存放新文本后，使用 mid$ 函数在正确位置插入文本。tostring 函数将返回当前存储在缓冲区中的文本，并将缓冲区的大小调整为能够容纳此文本的正确长度。使用 stringbuilder 的 asp 代码如下所示：


function writehtml（ data ）
dim osb
dim nrep
set osb = server.createobject（ "stringbuildervb.stringbuilder" ）
' 用大小和增长系数初始化缓冲区
osb.init 15000, 7500
for nrep = 0 to 99
osb.append "＜tr＞＜td＞", （nrep + 1）, "＜/td＞＜td＞", _
data（ 0, nrep ）, "＜/td＞＜td＞", _
data（ 1, nrep ）, "＜/td＞＜td＞", _
data（ 2, nrep ）, "＜/td＞＜td＞", _
data（ 3, nrep ）, "＜/td＞＜td＞", _
data（ 4, nrep ）, "＜/td＞＜td＞", _
data（ 5, nrep ）, "＜/td＞＜/tr＞"
next
writehtml = osb.tostring（）
set osb = nothing
end function

　　使用 stringbuilder 需要一定的开销，因为每次使用此类时都必须创建它的实例，并且在创建第一个类实例时必须加载包含此类的 dll。对 stringbuilder 实例进行额外方法调用时也需要开销。使用加括号的“&”方法时，stringbuilder 如何执行取决于多个因素，包括连接的数目、要构建的字符串的大小以及选择的 stringbuilder 字符串缓冲区的初始化参数的性能。请注意，在多数情况下，将缓冲区中所需的空间量估计得略高一些要远远好于让其不断增长。

　　内置方法

　　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 文档。以下原则可以帮助您确定哪种方法最适合您的需要。

　　首先尝试加括号的“&”方法，尤其是在处理现有代码时。这种方法对代码结构的影响微乎其微，但您会发现应用程序的性能将显著增强，甚至会超出预定目标。

　　在不破坏所需的封装级别的情况下使用 response.write。使用此方法，可以避免不必要的内存内字符串处理，从而提供最佳的性能。

　　使用 stringbuilder 构建真正大型或连接数目较多的字符串。

　　尽管您可能未看到本文所示的这种性能增长，但我已在真实的 asp web 应用程序中使用了这些技巧，只需要很少的额外投入就可以在性能和可缩放性方面获得很大的提高。