经典asp的性能提示?
Posted
技术标签:
【中文标题】经典asp的性能提示?【英文标题】:Performance tips for classic asp? 【发布时间】:2009-02-26 17:49:58 【问题描述】:今天我的任务是改进经典 ASP 页面的性能。在 ASP.NET 中重写代码目前不是一种选择,因此我接受了挑战,以充分利用我可以从页面中获得的每一盎司性能。
该页面包含基本的“SELECT bla bla FROM bla”到几个记录集。 while 循环遍历这些记录集并转储
所以没有什么真正令人震惊的东西。在我开始优化之前,循环大约需要 15 秒才能完成。在 15 秒中,大约 6 秒被 sql 查询占用。
在改变了一些东西之后,我设法把它弄到了 7 秒左右。
我改变的地方是:
我没有执行 SELECT *,而是只选择了我需要的列。查询平均下降到 4 秒。这是一个非常繁重的查询,其中包含视图。
我删除了循环内的所有上下文切换。因此,我将 之类的内容更改为 Response.Write(bla)。
这 3 个子程序被定义为函数,但它们被用作子程序(没有结果)。所以我把函数改成了subs。这有帮助吗?
进行更改后,我发现大部分时间都被其中一个子例程占用了。我今天没有足够的时间来更改子程序,但它包含以下内容:
日期函数:Dateadd、Datediff 数组函数:Ubound(arr) 和索引引用:arr(I) 字符串函数:左、中、右、下、替换每次调用页面时,该子例程都会运行大约 1600 次。
有人有优化经典asp页面的经验吗?你有什么好的优化技巧吗?我正在寻找的是改进 do ... 循环语句中的代码。
我是一位经验丰富的 ASP.NET 开发人员,并且对 ASP.NET 的性能改进非常了解。经典 ASP 使用不同的“引擎”,所以我想知道是否有人对提高经典 ASP 的性能有任何见解。
谢谢!
M
PS:是的,我知道经典的 ASP 使用 VBScript
【问题讨论】:
GetRows 这将创建您寻求的速度。这里是我用过的some other tips。
【讨论】:
【参考方案2】:看到这是一个流行的问题,我决定解释一下我在 3 年前所做的加速 ASP 脚本的事情。
原始脚本大量使用可调整大小的数组来存储键值,因此我修改了该代码以使用 Scriting.Dictionary。示例:
Dim myDictionary
Set myDictionary = Createobject("Scripting.Dictionary")
myDictionary.item("key") = "value"
这比可调整大小的数组快得多。
另一个很大的变化是字符串的连接。原始脚本充满了:
S = ""
S = S & "First line<br />"
S = S & "Second line<br />"
S = S & "Third line line<br />"
Response.Write(S)
我修改为:
Response.Write("First line<br />")
Response.Write("Second line<br />")
Response.Write("Third line<br />")
这有很大的不同。字符串的连接是一个巨大的瓶颈,因为字符串被丢弃然后重新初始化。
另一种选择是:
S = "First line<br />" & _
"Second line<br />" & _
"Third line line<br />"
Response.Write(S)
这也是 ASP.NET 的一个很好的提示:使用 StringBuilder 而不是连接字符串。
另一个重要的变化是上下文切换。原代码满是:
<table>
<tr>
<td><%= rs("Col1") %></td>
<td><%= rs("Col2") %></td>
<td><%= rs("Col2") %></td>
</tr>
</table>
3 个上下文切换占用了大量时间,所以我修改为:
<%
Response.Write("<table>")
Response.Write("<tr>")
Response.Write("<td>")
Response.Write(rs("Col1"))
Response.Write("</td>")
Response.Write("</tr>")
Response.Write("<tr>")
Response.Write("<td>")
Response.Write(rs("Col2"))
Response.Write("</td>")
Response.Write("</tr>")
Response.Write("<tr>")
Response.Write("<td>")
Response.Write(rs("Col3"))
Response.Write("</td>")
Response.Write("</tr>")
Response.Write("</table>")
%>
是的,代码非常冗余,但性能更好。
另一个小的修改(实际上是一个肮脏的黑客)是在你的 SQL 查询中使用 WITH (NOLOCK):
conn.Query("SELECT * FROM MyTable WITH (NOLOCK) LEFT JOIN AnotherTable WITH (NOLOCK) ON MyTable.Id = AnotherTable.Id")
这很重要。
最后,我不知道这是否有多大帮助,但有很多复制粘贴的代码我重构为干净的函数。
我希望找到此广告的人们会发现这些提示很有用。
【讨论】:
我的评论被否决为 0?真的吗?投反对票的人真的读过帖子吗?【参考方案3】:每次调用页面时,该子例程都会运行大约 1600 次。
我想说这几乎是整个问题,但不知道返回查询的数据的详细信息、该子例程的作用以及为什么它需要为一个页面执行 1600 次,很难建议降低它。
【讨论】:
这是一个计划应用程序,构建它的人热情地创建了一个大的 while 循环,显示整个月的大量记录的计划(30 列和大约 20 行)。【参考方案4】:我将 MrChrister 的回答标记为对我的问题“您有什么好的优化技巧吗?”的回答。那里的提示很好,它设法将脚本加速了 2 秒。
我最终发现是什么让脚本变慢了。在 while 循环中,程序员做了很多 Filter(Array)。他基本上是使用 Filter(Array) 来查找键/值对。
所以最终的解决方案是将 Filter(Array) 的代码更改为使用“Scripting.Dictionary”对象。它将代码速度提高了 12 倍。
感谢您的所有回复。
M
【讨论】:
【参考方案5】:如果你真的认为问题出在那1个函数上,为什么不把代码放在这里,以便人们提出优化建议。
【讨论】:
不幸的是,我不拥有该代码。我可能会因为发布它而遇到麻烦。该函数基本上基于记录集构建字符串,但拼接和连接,然后使用 response.write 转储它。标准的东西。 不幸的是,当你在做标准的东西时很难给出建议,而且我们无法访问代码。 :) 就像乍得说的,也许你可以多想想“为什么”。或者,也许您可以尝试将一堆操作移至存储过程。 我想知道是否是导致问题的连接。 VB 以不能很好地处理字符串的 concat 而闻名...寻找一种写入屏幕或创建长字符串的替代方法(想想数组或流对象)。【参考方案6】:我体验到,在大多数情况下,在经典 ASP 中使用 StringBuilder 可以获得性能。 ajaxed library 中有一个不错的 StringBuilder implementation 用于经典 ASP。它使用.net StringBuilder。这很酷且易于使用:
<%
set output = new StringBuilder
do
output("some output")
loop
response.write(output.toString())
%>
如果您需要进行一些调整,我建议您使用 ajaxed 库。它设置迅速,并为您提供了许多经典 ASP 的工具。例如。也许您在使用 AJAX 时也可以获得一些性能(或者至少是性能的印象)。
【讨论】:
以上是关于经典asp的性能提示?的主要内容,如果未能解决你的问题,请参考以下文章
检测到在集成的托管管道模式下不适用的ASP.NET设置的解决方法(非简单设置为经典模式)。 - CatcherX