1.重用HTTPCLIENT實例。
一般說來,建議一個通訊組件,甚至說一個應用軟件就始終維持一個HttpClient對象實例存在。但是如果你的應用很稀罕才用到它,而且還不允許這么一個實例一直存在,那么,這里強烈建議,每次在disposing 它之前,一定要顯式地shut down 它的 multithreaded connection manager 。這樣做是確保連接池里的connection得到釋放。
2.持續連接不關閉。
httpclient總是盡量重用連接。它不要求任何配置,默認情況下就是這樣。某些情況下,這可能導致連接泄漏,而耗盡資源。禁用持續連接最簡單的方法是提供或擴展一個connection manager,在releaseConnection被調用的時候,這個connection manager將把connection真正關閉掉。
3.http method的并發執行。(實際上是在對1.延伸)如果應用程序邏輯允許并發執行多個HTTP請求,(例如對多個服務器的多個并發請求,或對同一個服務器代表不同用戶身份的多個請求) ,應用程序可以為每一個HTTP session開啟一個專門的線程,這樣的設計自然將帶來顯著的性能提升。 而當使用一個線程安全的連接管理器,如multithreadedhttpconnectionmanager時,HttpClient能保證線程安全。這樣,多個線程可以共享這么一個線程安全的HttpClient實例。請注意,應用程序的每個各自執行的線程必須使用各自的httpmethod實例;并且可配置各自的httpstate實例和/或hostconfiguration實例(代表一個特定的會話狀態和主機配置)。這個共享的HttpClient和其標配的multithreadedhttpconnectionmanager將為各線程帶來最高的性能。
4.request/response entity 流技術處理
HttpClient能夠有效地流處理request,response。就是說大的entity可以不用在內存(泛濫)緩存就發送或接收。這點在多請求并發時尤其關鍵。雖然提供了方法可以通過訪問字符串或字節組的方式處理數據(而不是通過流),但是不建議這樣做。因為除非特別仔細,這樣做很容易引起內存溢出,因為這些方法實際上是把整個entity都緩存在了內存中。
response流API:建議使用HttpMethod#getResponseBodyAsStream,將response體作為字節/字符流處理;不建議使用HttpMethod#getResponseBody 和HttpMethod#getResponseBodyAsString 。
request流API:對于request的流處理,技術難題在于如果通訊過程出現問題(認證失敗或io失敗),那么需要對發送的request entity進行重新獲取,重新發送。很明顯,(request的數據來源于應用程序的各個方面),除了可以提供API(NameValuePair 形式)處理可完全緩存在內存的數據(字節組等),不容易提供統一的API。因此(對于大塊的entity),程序員可通過自行繼承RequestEntity,在相應回調方法里進行流化處理。
5.Expect-continue handshake
HTTP提供HTTP 100 (Continue) 狀態,是指客戶端發送一個“預期HTTP100”的請求header,如果服務器響應100說明接受該客戶端請求,則客戶端繼續發送body。是啊,如果服務器通過header就能判斷是否響應100還是拒絕,那么不通過這條路就直接發送body(尤其是大body)真的太浪費資源了。授權拒絕是最典型的情形了。因此強烈建議對于那些有HTTP認證要求的服務器使用“預期HTTP100”這種通訊方式。注意如果通訊要通過代理,程序員要處理可能的警告,因為一些老的HTTP1.0代理服務器不能正確處理“預期HTTP100”通訊方式。
6. 鈍態連接的檢查
HTTP協議規范允許客戶端或服務器端不知會對方,在任意時刻都可以終止一個連接(指底層網絡連接),因此這個connection就變成了鈍態或者說陳舊了,反正是不能用了。在默認情況下,HttpClient 會在執行HTTP方法前檢查要用的連接,看看是否是鈍態。這個檢查需耗時15-30ms,根據使用的jre不同而不同。關閉這個檢查能帶來小部分的性能提升,尤其對于小負載response這種通訊。但是關閉后可能面臨底層連接已關閉的異常(服務器主動關閉但沒通知客戶端)。
7.Cookie 處理
如果一個應用程序,例如web spider,不需要和服務器保持會話狀態,則禁用cookie會帶來輕微的性能提升。