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