問題一：過多的數據庫調用
我們發現經常出現的一個問題就是在每次請求/事務中存在過多的數據庫查詢。有如下三個場景作爲佐證
在一次事務上下文中所請求的數據比實際需要的數據多出很多。比如說：請求所有的賬戶信息而不是僅僅查詢出當前需要顯示的信息。
多次請求同樣的數據。這種情況通常發生在相同事務中的不同組件之間是彼此獨立的，而每個組件都會請求同樣的數據。我們並不清楚當前上下文中已經加載了哪些數據，最後只得多次發出同樣的查詢。
發出多個查詢語句以獲得某一數據集。通常這是由於沒有充分利用到複雜的SQL語句、存儲過程等在一次批處理中獲取需要的數據所導致的。
問題二：過多地使用同步
毫無疑問，同步對於應用中共享數據的保護來說是至關重要的舉措。但有很多開發者卻過度使用同步，比如在超大段的代碼中使用同步。在低負載的情況下，這麼做倒沒什麼問題；但在高負載或是產品環境下，過度的同步會導致嚴重的性能與可伸縮性問題。
問題三：過度使用遠程調用
很多庫都使用了遠程通信。對於開發者來說，遠程調用與本地調用似乎沒什麼區別，但如果不清楚遠程調用的本質就會鑄成大錯，因爲每一次遠程調用都會涉及到延遲、序列化、網絡堵塞以及內存使用等問題。如果沒有經過深思熟慮而盲目使用這些遠程技術就會導致嚴重的性能與可伸縮性問題。
問題四：錯誤地使用對象關係映射
對象關係映射爲開發者解決了很多負擔，比如從數據庫中加載對象以及將對象持久化到數據庫中。但與其他任何框架一樣，對象關係映射也有很多配置選項需要優化，只有這樣才能適應於當前應用的需要。錯誤的配置與不正確的使用都會導致始料不及的性能問題。在使用對象關係映射框架前，請務必保證熟悉所有的配置，如果有機會，請深入到所用框架的內核，這樣使用起來纔有保障。
問題五：內存泄漏
託管的運行時環境（如Java和.NET）可以通過垃圾收集器進行內存管理。但垃圾收集器無法避免內存泄漏問題。“被遺忘”的對象依舊會佔據着內存，最終將會導致內存泄漏問題。當對象不再需要時，請儘快釋放掉對象引用。
問題六：使用有問題的第三方代碼/組件
沒有人會從頭編寫應用的全部功能。我們都會使用第三方程序庫來加快開發進程。這麼做不僅會加速產出，也增加了性能上的風險。雖然大多數框架都具有良好的文檔並且經過了充分的測試，但沒人能夠保證這些框架在任何時候都會像預期的那樣好。因此，在使用這些第三方框架時，事先一定要做好充分的調研。
問題七：對稀缺資源的使用存在浪費的情況
內存、CPU、I/O以及數據庫等資源屬於稀缺資源。在使用這些資源時如果存在浪費的情況就會造成嚴重的性能與可伸縮性問題。比如說，有人會長時間打開數據庫連接而不關閉。連接應該只在需要的時候才使用，使用完畢後就應該放回到連接池中。我們經常看到有人在請求一開始就去獲取連接，直到最後才釋放，這麼做會導致性能瓶頸。
問題八：膨脹的Web前端
由於現在的Web速度越來越快，用戶的網絡體驗也越來越好。在這個趨勢下，很多應用的前端都提供了太多的內容，但這麼做會導致差勁的瀏覽體驗。很多圖片都太大了，沒有利用好或是錯誤地使用了瀏覽器緩存、過度地使用JavaScript/AJAX等，所有這一切都會導致瀏覽器的性能問題。
問題九：錯誤的緩存策略導致過度的垃圾收集
將對象緩存在內存中可以避免每次都向數據庫發出請求，這麼做可以提升性能。但如果緩存了太多的對象，或是緩存了很多不常使用的對象則會將緩存的這種優勢變成劣勢，因爲這會導致過高的內存使用率及過多的垃圾收集活動。在實現緩存策略前，請想好哪些對象需要緩存，哪些對象不需要緩存，進而避免這類性能與可伸縮性問題。
問題十：間歇性問題
間歇性問題很難發現。通常這類問題與特定的輸入參數有關，或是發生在某個負載條件下。完全的測試覆蓋率及負載與性能測試能在這些問題產生前就發現他們。