Posted on 2008-08-12 14:29
英雄 閱讀(5300)
評(píng)論(0) 編輯 收藏
httpclient的默認(rèn)配置提供了最大的可靠性和標(biāo)準(zhǔn)的遵守，而不是性能。（哪個(gè)標(biāo)準(zhǔn)？難道是指HTTP協(xié)議規(guī)范？）有幾個(gè)配置選項(xiàng)和優(yōu)化技術(shù)，可以顯著提高h(yuǎn)ttpclient 的性能表現(xiàn)。 本文檔給出了對(duì)httpclient如何調(diào)優(yōu)的大綱。
1.重用HTTPCLIENT實(shí)例。
一般說來，建議一個(gè)通訊組件，甚至說一個(gè)應(yīng)用軟件就始終維持一個(gè)HttpClient對(duì)象實(shí)例存在。但是如果你的應(yīng)用很稀罕才用到它，而且還不允許這么一個(gè)實(shí)例一直存在，那么，這里強(qiáng)烈建議，每次在disposing 它之前，一定要顯式地shut down 它的 multithreaded connection manager 。這樣做是確保連接池里的connection得到釋放。
2.持續(xù)連接不關(guān)閉。
httpclient總是盡量重用連接。它不要求任何配置，默認(rèn)情況下就是這樣。某些情況下，這可能導(dǎo)致連接泄漏，而耗盡資源。禁用持續(xù)連接最簡(jiǎn)單的方法是提供或擴(kuò)展一個(gè)connection manager，在releaseConnection被調(diào)用的時(shí)候，這個(gè)connection manager將把connection真正關(guān)閉掉。
3.http method的并發(fā)執(zhí)行。（實(shí)際上是在對(duì)1.延伸）
如果應(yīng)用程序邏輯允許并發(fā)執(zhí)行多個(gè)HTTP請(qǐng)求，（例如對(duì)多個(gè)服務(wù)器的多個(gè)并發(fā)請(qǐng)求，或?qū)ν粋€(gè)服務(wù)器代表不同用戶身份的多個(gè)請(qǐng)求） ，應(yīng)用程序可以為每一個(gè)HTTP session開啟一個(gè)專門的線程，這樣的設(shè)計(jì)自然將帶來顯著的性能提升。 而當(dāng)使用一個(gè)線程安全的連接管理器，如multithreadedhttpconnectionmanager時(shí)，HttpClient能保證線程安全。這樣，多個(gè)線程可以共享這么一個(gè)線程安全的HttpClient實(shí)例。請(qǐng)注意，應(yīng)用程序的每個(gè)各自執(zhí)行的線程必須使用各自的httpmethod實(shí)例；并且可配置各自的httpstate實(shí)例和/或hostconfiguration實(shí)例（代表一個(gè)特定的會(huì)話狀態(tài)和主機(jī)配置）。這個(gè)共享的HttpClient和其標(biāo)配的multithreadedhttpconnectionmanager將為各線程帶來最高的性能。
4.request/response entity 流技術(shù)處理
HttpClient能夠有效地流處理request,response。就是說大的entity可以不用在內(nèi)存（泛濫）緩存就發(fā)送或接收。這點(diǎn)在多請(qǐng)求并發(fā)時(shí)尤其關(guān)鍵。雖然提供了方法可以通過訪問字符串或字節(jié)組的方式處理數(shù)據(jù)（而不是通過流），但是不建議這樣做。因?yàn)槌翘貏e仔細(xì)，這樣做很容易引起內(nèi)存溢出，因?yàn)檫@些方法實(shí)際上是把整個(gè)entity都緩存在了內(nèi)存中。
response流API：建議使用HttpMethod#getResponseBodyAsStream，將response體作為字節(jié)/字符流處理；不建議使用HttpMethod#getResponseBody 和HttpMethod#getResponseBodyAsString 。
request流API：對(duì)于request的流處理，技術(shù)難題在于如果通訊過程出現(xiàn)問題（認(rèn)證失敗或io失敗），那么需要對(duì)發(fā)送的request entity進(jìn)行重新獲取,重新發(fā)送。很明顯，(request的數(shù)據(jù)來源于應(yīng)用程序的各個(gè)方面)，除了可以提供API（NameValuePair 形式）處理可完全緩存在內(nèi)存的數(shù)據(jù)（字節(jié)組等），不容易提供統(tǒng)一的API。因此（對(duì)于大塊的entity），程序員可通過自行繼承RequestEntity，在相應(yīng)回調(diào)方法里進(jìn)行流化處理。
5.Expect-continue handshake
HTTP提供HTTP 100 (Continue) 狀態(tài)，是指客戶端發(fā)送一個(gè)“預(yù)期HTTP100”的請(qǐng)求header，如果服務(wù)器響應(yīng)100說明接受該客戶端請(qǐng)求，則客戶端繼續(xù)發(fā)送body。是啊，如果服務(wù)器通過header就能判斷是否響應(yīng)100還是拒絕，那么不通過這條路就直接發(fā)送body（尤其是大body）真的太浪費(fèi)資源了。授權(quán)拒絕是最典型的情形了。因此強(qiáng)烈建議對(duì)于那些有HTTP認(rèn)證要求的服務(wù)器使用“預(yù)期HTTP100”這種通訊方式。注意如果通訊要通過代理，程序員要處理可能的警告，因?yàn)橐恍├系腍TTP1.0代理服務(wù)器不能正確處理“預(yù)期HTTP100”通訊方式。
6. 鈍態(tài)連接的檢查
HTTP協(xié)議規(guī)范允許客戶端或服務(wù)器端不知會(huì)對(duì)方，在任意時(shí)刻都可以終止一個(gè)連接（指底層網(wǎng)絡(luò)連接），因此這個(gè)connection就變成了鈍態(tài)或者說陳舊了，反正是不能用了。在默認(rèn)情況下，HttpClient 會(huì)在執(zhí)行HTTP方法前檢查要用的連接，看看是否是鈍態(tài)。這個(gè)檢查需耗時(shí)15-30ms，根據(jù)使用的jre不同而不同。關(guān)閉這個(gè)檢查能帶來小部分的性能提升，尤其對(duì)于小負(fù)載response這種通訊。但是關(guān)閉后可能面臨底層連接已關(guān)閉的異常（服務(wù)器主動(dòng)關(guān)閉但沒通知客戶端）。
7.Cookie 處理
如果一個(gè)應(yīng)用程序，例如web spider，不需要和服務(wù)器保持會(huì)話狀態(tài)，則禁用cookie會(huì)帶來輕微的性能提升。