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