之前曾報(bào)道過《“殺死”你的服務(wù)器的6種方法》，分析了在網(wǎng)站后臺(tái)重構(gòu)過程中容易讓服務(wù)器宕機(jī)的六種情況，本文作者則列舉了其在過去幾年工作中所遇到的服務(wù)器端編程的十大性能問題。

成都創(chuàng)新互聯(lián)長期為成百上千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為宜興企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、成都網(wǎng)站制作，宜興網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

問題一：過多的數(shù)據(jù)庫調(diào)用

我們發(fā)現(xiàn)經(jīng)常出現(xiàn)的一個(gè)問題就是在每次請求/事務(wù)中存在過多的數(shù)據(jù)庫查詢。有如下三個(gè)場景作為佐證：

◆在一次事務(wù)上下文中所請求的數(shù)據(jù)比實(shí)際需要的數(shù)據(jù)多出很多。比如說：請求所有的賬戶信息而不是僅僅查詢出當(dāng)前需要顯示的信息。

◆多次請求同樣的數(shù)據(jù)。這種情況通常發(fā)生在相同事務(wù)中的不同組件之間是彼此獨(dú)立的，而每個(gè)組件都會(huì)請求同樣的數(shù)據(jù)。我們并不清楚當(dāng)前上下文中已經(jīng)加載了哪些數(shù)據(jù)，最后只得多次發(fā)出同樣的查詢。

◆發(fā)出多個(gè)查詢語句以獲得某一數(shù)據(jù)集。通常這是由于沒有充分利用到復(fù)雜的SQL語句、存儲(chǔ)過程等在一次批處理中獲取需要的數(shù)據(jù)所導(dǎo)致的。

問題二：過多地使用同步

毫無疑問，同步對于應(yīng)用中共享數(shù)據(jù)的保護(hù)來說是至關(guān)重要的舉措。但有很多開發(fā)者卻過度使用同步，比如在超大段的代碼中使用同步。在低負(fù)載的情況下，這么做倒沒什么問題；但在高負(fù)載或是產(chǎn)品環(huán)境下，過度的同步會(huì)導(dǎo)致嚴(yán)重的性能與可伸縮性問題。

問題三：過度使用遠(yuǎn)程調(diào)用

很多庫都使用了遠(yuǎn)程通信。對于開發(fā)者來說，遠(yuǎn)程調(diào)用與本地調(diào)用似乎沒什么區(qū)別，但如果不清楚遠(yuǎn)程調(diào)用的本質(zhì)就會(huì)鑄成大錯(cuò)，因?yàn)槊恳淮芜h(yuǎn)程調(diào)用都會(huì)涉及到延遲、序列化、網(wǎng)絡(luò)堵塞以及內(nèi)存使用等問題。如果沒有經(jīng)過深思熟慮而盲目使用這些遠(yuǎn)程技術(shù)就會(huì)導(dǎo)致嚴(yán)重的性能與可伸縮性問題。

問題四：錯(cuò)誤地使用對象關(guān)系映射

對象關(guān)系映射為開發(fā)者解決了很多負(fù)擔(dān)，比如從數(shù)據(jù)庫中加載對象以及將對象持久化到數(shù)據(jù)庫中。但與其他任何框架一樣，對象關(guān)系映射也有很多配置選項(xiàng)需要優(yōu)化，只有這樣才能適應(yīng)于當(dāng)前應(yīng)用的需要。錯(cuò)誤的配置與不正確的使用都會(huì)導(dǎo)致始料不及的性能問題。在使用對象關(guān)系映射框架前，請務(wù)必保證熟悉所有的配置，如果有機(jī)會(huì)，請深入到所用框架的內(nèi)核，這樣使用起來才有保障。

問題五：內(nèi)存泄漏

托管的運(yùn)行時(shí)環(huán)境（如Java和.NET）可以通過垃圾收集器進(jìn)行內(nèi)存管理。但垃圾收集器無法避免內(nèi)存泄漏問題?！氨贿z忘”的對象依舊會(huì)占據(jù)著內(nèi)存，最終將會(huì)導(dǎo)致內(nèi)存泄漏問題。當(dāng)對象不再需要時(shí)，請盡快釋放掉對象引用。

問題六：使用有問題的第三方代碼/組件

沒有人會(huì)從頭編寫應(yīng)用的全部功能。我們都會(huì)使用第三方程序庫來加快開發(fā)進(jìn)程。這么做不僅會(huì)加速產(chǎn)出，也增加了性能上的風(fēng)險(xiǎn)。雖然大多數(shù)框架都具有良好的文檔并且經(jīng)過了充分的測試，但沒人能夠保證這些框架在任何時(shí)候都會(huì)像預(yù)期的那樣好。因此，在使用這些第三方框架時(shí)，事先一定要做好充分的調(diào)研。

問題七：對稀缺資源的使用存在浪費(fèi)的情況

內(nèi)存、CPU、I/O以及數(shù)據(jù)庫等資源屬于稀缺資源。在使用這些資源時(shí)如果存在浪費(fèi)的情況就會(huì)造成嚴(yán)重的性能與可伸縮性問題。比如說，有人會(huì)長時(shí)間打開數(shù)據(jù)庫連接而不關(guān)閉。連接應(yīng)該只在需要的時(shí)候才使用，使用完畢后就應(yīng)該放回到連接池中。我們經(jīng)?？吹接腥嗽谡埱笠婚_始就去獲取連接，直到最后才釋放，這么做會(huì)導(dǎo)致性能瓶頸。

問題八：膨脹的Web前端

由于現(xiàn)在的Web速度越來越快，用戶的網(wǎng)絡(luò)體驗(yàn)也越來越好。在這個(gè)趨勢下，很多應(yīng)用的前端都提供了太多的內(nèi)容，但這么做會(huì)導(dǎo)致差勁的瀏覽體驗(yàn)。很多圖片都太大了，沒有利用好或是錯(cuò)誤地使用了瀏覽器緩存、過度地使用JavaScript/AJAX等，所有這一切都會(huì)導(dǎo)致瀏覽器的性能問題。

問題九：錯(cuò)誤的緩存策略導(dǎo)致過度的垃圾收集

將對象緩存在內(nèi)存中可以避免每次都向數(shù)據(jù)庫發(fā)出請求，這么做可以提升性能。但如果緩存了太多的對象，或是緩存了很多不常使用的對象則會(huì)將緩存的這種優(yōu)勢變成劣勢，因?yàn)檫@會(huì)導(dǎo)致過高的內(nèi)存使用率及過多的垃圾收集活動(dòng)。在實(shí)現(xiàn)緩存策略前，請想好哪些對象需要緩存，哪些對象不需要緩存，進(jìn)而避免這類性能與可伸縮性問題。

問題十：間歇性問題

間歇性問題很難發(fā)現(xiàn)。通常這類問題與特定的輸入?yún)?shù)有關(guān)，或是發(fā)生在某個(gè)負(fù)載條件下。完全的測試覆蓋率及負(fù)載與性能測試能在這些問題產(chǎn)生前就發(fā)現(xiàn)他們。

原文作者：Andreas Grabner

原文鏈接：http://blog.dynatrace.com/2010/06/15/top-10-performance-problems-taken-from-zappos-monster-and-co/

作者介紹

Andreas Grabner，是一名具有10年以上編程經(jīng)驗(yàn)的Java/.Net開發(fā)工程師，他目前是職位是dynaTrace軟件公司技術(shù)團(tuán)隊(duì)的負(fù)責(zé)人。

【編輯推薦】 

1. “殺死”你的服務(wù)器的6種方法
2. 大型B2C網(wǎng)站高性能可伸縮架構(gòu)技術(shù)探秘
3. 世界最大的PHP站點(diǎn) Facebook后臺(tái)技術(shù)探秘
4. 更好的選擇 細(xì)數(shù)Apache服務(wù)器的四個(gè)替代者

當(dāng)前名稱：服務(wù)器端編程的十大性能問題
標(biāo)題URL：http://uogjgqi.cn/article/dhecgdp.html