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