兩個ASP的效能最佳化實用方法

來源:互聯網
上載者:User
效能|最佳化 1.討論主題:ASP指令碼大小

你的指令碼頁(還有其它頁面)是不是比必須的長度要長?
這是一開始執行就會降低Asp效能的東西。ASP指令碼在用來擷取資訊和格式化輸出的時候是十分有用的,但指令碼也是逐行解釋執行,所以你的指令碼越長,執行它的時間也就越長。

如果你的指令碼很龐大,怎麼做才能減少指令碼的長度呢?
這裡有幾點建議:
你可以將它們轉換成伺服器端組件,也就是說,做成VB動態連結程式庫DLL或者通過先進的Windows程式設計語言或適當的COM介面語言將它轉換成未編譯組件?並且在伺服器端註冊它們。有關的快速指南可以在找到。對一個寫得好的ActiveX組件進行編譯不但能大幅度提高效能,還可以保護你的軟體(指令碼),尤其當你將你的Asp網站發布在第三方主機上的時候。
因為指令碼是逐行解釋執行的,所以剔除多餘的指令碼或建立更高效率的指令碼能夠改進效能。如果你在單個Asp檔案中有數百行的代碼,可能這樣做你能很好地劃分使用者,買賣和資料服務。事實上,如果你這樣做,可能會找出一些冗餘的代碼:如果你需要輸出幾個表格,你可以編寫一個通用函數來輸出一個表格,只是多次調用它。
在講述Asp指令碼的大小問題的時候,不得不提及包含檔案的大小。當你使用一個包含檔案的時候,整個包含檔案被裝入,當包含檔案被包含的時候,相當於在Asp檔案本身寫下那部分代碼。因此,如果你在一個冗長的包含檔案裡定義了很多通用的方法和定義,要明白到在你包含該檔案的時候,不管你要不要用到裡面的每個方法和定義,它都是被整個裝入的。ASP緩衝全部的展開代碼,這會降低尋找效率在這種情況下,包含檔案必須被分割成更小的,模組化的檔案。也要明白到包含檔案被伺服器視為單獨的頁面請求,使用太多的包含檔案會影響下載時間。

<!--#includefile="Header.asp"-->
<!--#includefile="Footer.asp"-->
<SCRIPTlanguage="vbscript"runat="server">

SubMain()
WriteHeader
WriteBody
WriteFooter
EndSub

SubWriteBody()
...
EndSub

Main'調用過程Main
</SCRIPT>

假如你的指令碼冗長的話,請使用Response.IsClientConnected。這意味著在用戶端不再串連到服務
器的時候,你的伺服器CPU能避免迴圈等待。

<%
'檢查用戶端是否仍在串連
IfNotResponse.IsClientConnectedThen
'仍然串連著,處理常式
Else
'斷開
EndIf
%>



使用快速的OLEDBProvider技術串連你的資料庫而不是使用DSN串連。不再需要懇求你的ISP(或資料庫管理員/網管)為你建立一個系統DSN,當你移走Web檔案的時候,亦不需要改變更配置置。
OLEDB介於ODBC層和應用程式之間。在你的ASP頁面中,ADO介於ODEDB之上的“應用程式”。你的ADO調用首先被送到OLEDB,接著被送到ODBC層。然而,你可以直接連接到OLEDB層,並且如果你這樣做的話,你就能看到伺服器端效能的提高。

然而,怎樣直接連接到OLEDB?
如果你使用SQLServer7,使用下面的串連代碼串連資料庫:

strConnString="DSN='';DRIVER={SQLSERVER};"&_
"UID=myuid;PWD=mypwd;"&_
"DATABASE=MyDb;SERVER=MyServer;"

最重要的參數是DRIVER=部分。如果你要繞過ODBC而使用通過使用OLEDB串連SQLServer(這是更快
的串連),請使用下面的文法:

strConnString="Provider=SQLOLEDB.1;Password=mypassword;"&_
"PersistSecurityInfo=True;UserID=myuid;"&_
"InitialCatalog=mydbname;"&_
"DataSource=myserver;ConnectTimeout=15"

有什麼不對的地方嗎?
現在你可能會覺得有點奇怪:我們在這個新的串連方法中的要點是什麼呢?為什麼不使用標準DSN-less/SystemDSN途徑?呵,根據Wrox在他的著作《ADO2.0Programmer'sReference》中測試的結果表明,如果你使用OLEDB串連和DSN或者DSN-less串連方法比較,你會發現有下面的改進:

效能對比:
SQLAccess
OLEDBDSNOLEDBDSN
連線時間:1882連線時間:6299
查詢1,000條記錄時間:29005400查詢1,000條記錄時間:100950

注釋:這個結果在Wrox的《ADO2.0Programmer'sReference》一書的第232和233頁可以查到。時間的單位是毫秒,查詢1,000記錄時間是通過伺服器端遊標計算出來的(當使用用戶端資料指標的時候,OLEDB與DSN記錄集的效能之間的差別不大)。


相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。