【文章內(nèi)容簡(jiǎn)介】
件的性能開(kāi)銷使得將組件遷移到托管代碼是值得的。每一情況都是 不一樣的,決定是否需要遷移組件的最好方法是對(duì) Web 站點(diǎn)運(yùn)行性能測(cè)量 。建議您研究一下如何將需要大量調(diào)用以進(jìn)行交互的任何 COM 組件遷移到托管代碼。許多情況下不可能將舊式組件遷移到托管代碼,特別是在最初遷移 Web 應(yīng)用程序時(shí)。在這種情況下,最大的性能障礙之一是將數(shù)據(jù)從非托管環(huán)境封送到托管環(huán)境。因此,在交互操作中,請(qǐng)?jiān)谌魏我欢藞?zhí)行盡可能多的任務(wù),然后進(jìn)行一個(gè) 大調(diào)用而不是一系列小調(diào)用。例如,公共語(yǔ)言運(yùn)行庫(kù)中的所有字符串都是 Unicode 的,所以應(yīng)在調(diào)用托管代碼之前將組件中的所有字符串轉(zhuǎn)換成 Unicode 格式。另外,一處理完任何 COM 對(duì)象或本機(jī)資源就釋放它們。這樣, 其他請(qǐng)求就能夠使用它們,并且最大限度地減少了因稍后請(qǐng)求垃圾回收器釋放它們所引起的性能問(wèn)題。 12. 在 Visual Basic .NET 或 JScript. 代碼中使用早期綁定 以往,開(kāi)發(fā)人員喜歡使用 Visual Basic、 VBScript. 和 JScript. 的原因之一就是它們所謂 “ 無(wú)類型 ” 的性質(zhì)。變量不需要顯式類型聲明,并能夠簡(jiǎn)單地通過(guò)使用來(lái)創(chuàng)建它們。當(dāng)從一個(gè)類型到另一個(gè)類型進(jìn)行分配時(shí),轉(zhuǎn)換將自動(dòng)執(zhí) 行。不過(guò),這種便利會(huì)大大損害應(yīng)用程序的性能。 Visual Basic 現(xiàn)在 通過(guò)使用 Option Strict 編譯器指令來(lái)支持類型安全編程。為了向后兼容,默認(rèn)情況下, 不啟用該選項(xiàng)。但是,為了得到最佳性能,強(qiáng)烈建議在頁(yè)中啟用該選項(xiàng)。若要啟用 Option Strict,請(qǐng)將 Strict 屬性包括在 @ Page 指令中,或者,對(duì)于用戶控件,請(qǐng)將該屬性包括在 @ Control 指令中。下面的示例演示了如何設(shè)置該屬性,并進(jìn)行了四個(gè)變量調(diào)用以顯示使用該屬性是如何導(dǎo)致編譯器錯(cuò)誤的。 %@ Page Language=VB Strict=true % % Dim B Dim C As String 39。 This will cause a piler error. A = Hello 39。 This will cause a piler error. B = World 39。 This will not cause a piler error. C = !!!!!! 39。 But this will cause a piler error. C = 0 % Dim B Dim C As String 39。 This will cause a piler error. A = Hello 39。 This will cause a piler error. B = World 39。 This will not cause a piler error. C = !!!!!! 39。 But this will cause a piler error. C = 0 % JScript. .NET 也支持無(wú)類型編程,但它不 提供強(qiáng)制早期綁定的編譯器指令。若發(fā)生下面任何一種情況,則變量是晚期綁定的:被顯式聲明為 Object,是無(wú)類型聲明的類的字段,是無(wú)顯式類型聲明的專用函數(shù)或方法成員,并且無(wú)法從其使用推斷出類型。 最后一個(gè)差別比較復(fù)雜,因?yàn)槿绻? JScript. .NET 編譯器可以根據(jù)變量的使用情況推斷出類型,它就會(huì)進(jìn)行優(yōu)化。在下面的示例中,變量 A 是早期綁定的,但變量 B 是晚期綁定的。 var A。 var B。 A = Hello。 B = World。 B = 0。 為了獲得 最佳的性能,當(dāng)聲明 JScript. .NET 變量時(shí),請(qǐng)為其分配一個(gè)類型。例如, var A : String。 13. 使請(qǐng)求管線內(nèi)的所有模塊盡可能高效 請(qǐng)求管線內(nèi)的所有模塊在每次請(qǐng)求中都有機(jī)會(huì)被運(yùn)行。因此,當(dāng)請(qǐng)求進(jìn)入和離開(kāi)模塊時(shí)快速地觸發(fā)代碼至關(guān)重要,特別是在不使用模塊功能的代碼路徑里。分別在使用及不使用模塊和配置文件時(shí)執(zhí)行吞吐量測(cè)試,對(duì)確定這些方法的執(zhí)行速度非常有用。 14. 使用 方法在同一應(yīng)用程序的頁(yè)面間重定向 采用 語(yǔ)法,在頁(yè)面中使用該方法可避免不必要的客戶端重定向。 15. 必要時(shí)調(diào)整應(yīng)用程序每個(gè)輔助進(jìn)程的線程數(shù) 的請(qǐng)求結(jié)構(gòu)試圖在執(zhí)行請(qǐng)求的線程數(shù)和可用資源之間達(dá)到一種平衡。已知一個(gè)使用足夠 CPU 功率的應(yīng)用程序,該結(jié)構(gòu)將根據(jù)可用于請(qǐng)求的 CPU 功率,來(lái)決定允許同時(shí)執(zhí)行的請(qǐng)求數(shù)。這項(xiàng)技術(shù)稱作線程門控。但是在某些條件下,線程門控算法不是很有效。通過(guò)使用與 Applications 性能對(duì)象關(guān)聯(lián)的 Pipeline Instance Count 性能計(jì)數(shù)器,可以在 PerfMon 中監(jiān)視線程門控。當(dāng)頁(yè)面調(diào)用外部資源,如數(shù)據(jù)庫(kù)訪問(wèn)或 XML Web services 請(qǐng)求時(shí),頁(yè)面請(qǐng)求通常停止并釋放 CPU。如果某個(gè)請(qǐng)求正在等待被處理,并且線程池中有一個(gè)線程是自由的,那么這個(gè)正在等待的請(qǐng)求將開(kāi)始被處理。遺憾的是,有時(shí)這可能導(dǎo)致 Web 服務(wù)器上存在大量同時(shí)處理的請(qǐng)求和許多正在等待的線程,而它們對(duì)服務(wù)器性能有不利影響。通常,如果門控因子是外部資源的響應(yīng)時(shí)間,則讓過(guò)多請(qǐng)求等待資源, 對(duì) Web 服務(wù)器的吞吐量并無(wú)幫助。為緩和這種情況,可以通過(guò)更改 配置文件節(jié)點(diǎn)的 maxWorkerThreads 和 maxIOThreads 屬性,手動(dòng)設(shè)置進(jìn)程中的線程數(shù)限制。 注意:輔助線程是