經典asp的性能提示？

Question

今天，我的任務是改善傳統ASP頁面的性能。在ASP.NET中重寫代碼現在不是一種選擇，所以我接受了挑戰，擠出每一盎司的性能，我可以離開頁面。

該頁面由基本的「SELECT bla bla FROM bla」組成一對記錄集。 while循環遍歷這些記錄集和轉儲<tr> <td>字符串。在while循環中有一堆條件和什麼。有3個子程序被調用，它們使用全局變量（不是作爲參數傳遞的本地變量）。

所以沒有什麼令人震驚或什麼。在我開始優化之前，循環需要大約15秒才能完成。在大約6秒的15秒內被sql查詢佔用。

改變了一些東西后，我設法得到它到7秒。

，我已經改變了周圍的事情是：

• 而不是做SELECT *的，我只選擇我需要的列。查詢平均下降到4秒。這是一個非常沉重的查詢視圖內的意見。

• 我刪除了循環內的所有上下文切換。所以我改變了如Response.Write（bla）<％= bla％>。

• 3個子程序被定義爲函數，但它們被用作子（沒有結果）。所以我把這些功能改成了subs。這有幫助嗎？

在做出更改後，我發現大部分時間都被其中一個子程序佔用。我沒有時間今天足以改變子程序，但它包含的東西，如：

• 日期函數：DATEADD，DATEDIFF
• 陣列功能：UBOUND（ARR）和指數參考：ARR（I）
• 字符串函數：左，中，右，下，更換

隨着每一個網頁呼叫，該子程序是圍繞1600次運行。

有沒有人有經驗優化經典的ASP頁面？你有什麼好的優化技巧？我正在尋找的是改進do ...循環語句中的代碼。

我是一位經驗豐富的ASP.NET開發人員，對ASP.NET的性能改進有相當的瞭解。經典的ASP使用不同的「引擎」，所以我想知道是否有人對改善傳統ASP的性能有任何見解。

謝謝！

中號

PS：是的，我知道，傳統的ASP使用VBScript中

Answer 1

GetRows這會創造你尋求的速度。這裏是我用過的some other tips。

Answer 2

隨着每一個網頁呼叫，該子程序是圍繞1600次運行。

我會說這幾乎是整個問題，但不知道數據的細節返回的查詢，什麼子程序呢，和爲什麼它需要做1600次的頁面時，它的很難建議降低它。

Answer 3

如果你真的認爲問題出在這1個函數中，爲什麼不把代碼放在這裏，以便人們可以提出優化建議。

Answer 4

我經歷過，在大多數情況下，您可以在傳統ASP中使用StringBuilder時獲得性能。在ajaxed library中有經典ASP的StringBuilder implementation。它使用.net StringBuilder。這很酷，易於使用：

<% 
set output = new StringBuilder 
do 
    output("some output") 
loop 
response.write(output.toString()) 
%> 

我會建議使用ajaxed庫，如果你需要做一些調整。它的設置很快，併爲您提供了很多經典ASP工具。例如。也許你也可以在使用AJAX時獲得一些性能（或者至少是性能的印象）。

Answer 5

我把MrChrister的回答標記爲我的問題「你有什麼好的優化技巧？」的答案。這裏的提示很好，它能夠加速腳本2秒。

我最終發現了腳本變慢的原因。在while循環中，程序員做了很多Filter（Array）。他基本上使用Filter（Array）來查找鍵/值對。

所以最終的解決方案是將Filter（Array）的代碼更改爲使用「Scripting.Dictionary」對象。它將代碼速度提高了12倍。

感謝您的回覆。

中號

Answer 6

看到，這是一個流行的問題，我已經決定要解釋什麼，我做了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") 

它的確與衆不同。最後，我不知道這是否有幫助，但有很多複製粘貼代碼，我重構成乾淨的功能。

我希望找到這個thead的人會發現這些提示很有用。