轉(zhuǎn)自： http://waterfox.javaeye.com/blog/709963
在最新一期的瑞士電腦雜志中，我們列出了這些年，用我們的客戶端所遇到的10個(gè)影響性能的突出問(wèn)題。我希望這個(gè)列表能夠給大家啟發(fā)。同時(shí)，為了更好的了解怎樣解決這些問(wèn)題，我引入了這些博客的鏈接。
#1 調(diào)用數(shù)據(jù)庫(kù)過(guò)多
我們見(jiàn)到的最多的問(wèn)題是，每次請(qǐng)求或事務(wù)，查詢數(shù)據(jù)庫(kù)的次數(shù)太多。這有3種特殊的現(xiàn)象來(lái)證實(shí)。
1. 在當(dāng)前事務(wù)的上下文中，請(qǐng)求的數(shù)據(jù)多于實(shí)際需要的數(shù)據(jù)。例如：請(qǐng)求所有用戶信息而不是那些我們要顯示到當(dāng)前屏幕的信息。
2. 同樣的數(shù)據(jù)被請(qǐng)求多次。這通常發(fā)生在不同的組件在同一個(gè)事務(wù)中彼此獨(dú)立的調(diào)用，并且每次都請(qǐng)求同類數(shù)據(jù)。因?yàn)椴恢滥姆N類型的數(shù)據(jù)已經(jīng)加載到當(dāng)前的上下文中，最終導(dǎo)致多次相同的查詢。
3. 為了取得一特定的數(shù)據(jù)集執(zhí)行多次查詢操作。這通常是因?yàn)闆](méi)有充分利用復(fù)雜 sql語(yǔ)句的優(yōu)點(diǎn)或存儲(chǔ)過(guò)程導(dǎo)致的。
想了解更多，請(qǐng)查看： Blog on Linq2Sql Performance Issues on Database , Video on Performance Anti-Patterns
#2 同步死鎖
毫無(wú)疑問(wèn)，同步在應(yīng)用中保護(hù)共享數(shù)據(jù)是十分必要的。但有很多開(kāi)發(fā)者犯了過(guò)度使用同步的錯(cuò)誤。例如：大量的代碼序列被同步。低負(fù)載（開(kāi)發(fā)者本地的機(jī)器上）時(shí)性能不會(huì)出現(xiàn)問(wèn)題。在高負(fù)載或生產(chǎn)環(huán)境中，同步過(guò)度使用會(huì)導(dǎo)致服務(wù)器性能和擴(kuò)展性問(wèn)題。
想了解更多哦，請(qǐng)查看：How to identify synchronization problems under load
#3 與遠(yuǎn)程通道對(duì)話過(guò)多
很多類庫(kù)出現(xiàn)使得遠(yuǎn)程通信看起來(lái)小菜一碟。開(kāi)發(fā)者調(diào)用本地和遠(yuǎn)程方法幾乎沒(méi)有什么不同。對(duì)遠(yuǎn)程調(diào)用的缺乏了解，使得大家 忘了 隨著每次遠(yuǎn)程調(diào)用產(chǎn)生的諸如延遲、序列化、網(wǎng)絡(luò)傳輸和內(nèi)存消耗等問(wèn)題。簡(jiǎn)單的使用這些技術(shù)導(dǎo)致這些遠(yuǎn)程邊界穿插太多的調(diào)用，最終導(dǎo)致性能和擴(kuò)展性問(wèn)題。
想了解更多，請(qǐng)查看： Performance Considerations in Distributed Applications
#4 錯(cuò)誤的使用O/R-Mappers
對(duì)象關(guān)系映射卸下了開(kāi)發(fā)者肩膀上的重?fù)?dān)-- 加載和在數(shù)據(jù)庫(kù)中持久化對(duì)象。任何一種框架通常有很多配置選項(xiàng)來(lái)優(yōu)化應(yīng)用用例的對(duì)象關(guān)系映射的使用。錯(cuò)誤的配置和不正確的使用框架本身過(guò)多，導(dǎo)致使用這些框架的不可預(yù)料的性能和擴(kuò)展性問(wèn)題。確保你自己熟悉所有的配置項(xiàng)并且了解你所依靠的類庫(kù)的內(nèi)部。
想了解更多，請(qǐng)查看： Understanding Hibernate Session Cache , Understanding the Query Cache , Understanding the Second Level Cache
#5 內(nèi)存泄漏
運(yùn)行時(shí)環(huán)境的管理，像Java和.NET都有垃圾回收器幫助進(jìn)行內(nèi)存管理。但是，垃圾回收器卻不能阻止內(nèi)存泄漏。被遺忘的對(duì)象會(huì)駐留在內(nèi)存中，最終導(dǎo)致內(nèi)存泄漏出現(xiàn)OutOfMemoryException。及時(shí)的釋放掉對(duì)不再需要的對(duì)象的引用很重要。
想了解更多，請(qǐng)查看： Understanding and finding Memory Leaks
#6 第三方代碼或組件的問(wèn)題
沒(méi)有人靠自己寫(xiě)一個(gè)新應(yīng)用的所有功能。我們使用第三方的類庫(kù)來(lái)加快我們的開(kāi)發(fā)進(jìn)度。我們?cè)诩涌煳覀冚敵龅耐瑫r(shí)，也增加了由這些組件帶來(lái)的性能風(fēng)險(xiǎn)。盡管多數(shù)的框架有很好的文檔且經(jīng)過(guò)十分徹底的測(cè)試，但不能保證這些框架適用于所有情況。他們經(jīng)常被不正確的使用，或不經(jīng)過(guò)測(cè)試就使用。所有，在引入你的代碼之前，要對(duì)所有這些框架進(jìn)行深入的檢查。
想了解更多，請(qǐng)查看： Top SharePoint Performance Mistakes
#7 稀少資源的浪費(fèi)使用
像內(nèi)存、CPU、I/O或數(shù)據(jù)庫(kù)這類資源都是稀少的。對(duì)這些資源的浪費(fèi)使用導(dǎo)致其他人不能調(diào)用這些資源，最終導(dǎo)致性能和擴(kuò)張性問(wèn)題。舉個(gè)例子：數(shù)據(jù)庫(kù)連接時(shí)間太長(zhǎng)。連接應(yīng)該只有在真正需要的期間段使用。例如，查詢時(shí)連接，然后把連接歸還給連接池。我們經(jīng)常看到在處理請(qǐng)求很早之前就請(qǐng)求連接，并且直到最后也沒(méi)有釋放連接，這就導(dǎo)致瓶頸現(xiàn)象的出現(xiàn)。
想了解更多，請(qǐng)查看： Resource Leak detection in .NET Applications
#8 臃腫的WEB前端
由于網(wǎng)絡(luò)的高速接入，用戶有了更好的用戶體驗(yàn)。不好的趨勢(shì)是很多應(yīng)用打包的東西太多，他們變得臃腫，最終導(dǎo)致瀏覽器出現(xiàn)錯(cuò)誤。那些還沒(méi)有高速網(wǎng)絡(luò)接入的用戶會(huì)遇到這樣的問(wèn)題會(huì)最多。圖片過(guò)大過(guò)多，錯(cuò)誤的使用瀏覽器的緩存，過(guò)度的使用JavaScript或Ajax，所有這些都會(huì)導(dǎo)致瀏覽器的性能問(wèn)題。按照已有網(wǎng)站的成功案例來(lái)優(yōu)化能解決這些問(wèn)題。
想了解更多，請(qǐng)查看： How Better Caching would help speed up Frankfurt Airport Web Site
#9 錯(cuò)誤的緩存策略導(dǎo)致垃圾回收過(guò)度
把對(duì)象在內(nèi)存中緩存，來(lái)避免持續(xù)的對(duì)數(shù)據(jù)庫(kù)的反復(fù)調(diào)用是提升性能的一種方法。緩存太多的對(duì)象，或者緩存的對(duì)象不是經(jīng)常使用，會(huì)把緩存的優(yōu)點(diǎn)變成缺點(diǎn)，因?yàn)橄牡膬?nèi)存過(guò)多并且增加了GC的活動(dòng)。在實(shí)現(xiàn)一個(gè)緩存策略之前，有應(yīng)該知道那些對(duì)象應(yīng)該緩存，哪些對(duì)象不應(yīng)該緩存來(lái)避免這些性能和擴(kuò)展性問(wèn)題。
想了解更多，請(qǐng)查看：Java Memory Problems , Identify GC Bottlenecks in Distributed Applications
#10 間歇性問(wèn)題
間歇性問(wèn)題很難被發(fā)現(xiàn)。這些問(wèn)題在輸入特殊參數(shù)或一定負(fù)載時(shí)才會(huì)經(jīng)常出現(xiàn)。測(cè)試覆蓋要全面，功能測(cè)試、負(fù)載測(cè)試和性能測(cè)試都要覆蓋到。這樣才能在成為最用用戶遇到的問(wèn)題之前發(fā)現(xiàn)這些問(wèn)題。
想了解更多，請(qǐng)查看： Tracing Intermittent Errors by Lucy Monahan from Novell , How to find invisible performance problems
（附加問(wèn)題）#11 昂貴的序列化
使用遠(yuǎn)程通信,像Web Service，RMI 或 WCF。對(duì)象需要被調(diào)用者序列化來(lái)在網(wǎng)絡(luò)中傳輸。網(wǎng)絡(luò)另一端的被調(diào)用者需要在使用這個(gè)對(duì)象前反序列化。傳輸時(shí)兩端都這樣做的話會(huì)導(dǎo)致一些資源消耗。知道兩端需要什么類型的序列化，哪種序列化和傳輸類型是最優(yōu)的很重要。不同類型的序列化對(duì)性能、擴(kuò)展性、內(nèi)存使用和網(wǎng)絡(luò)傳輸會(huì)產(chǎn)生不同的影響。
想了解更多，請(qǐng)查看：Performance Considerations in Distributed Applications
本文摘自：http://blog.dynatrace.com/2010/06/15/top-10-performance-problems-taken-from-zappos-monster-and-co/
翻譯的不好，見(jiàn)諒。