Max retries exceeded with url 解决方案
目錄
- 問題解決方案
- keep alive 與close使用場景
問題解決方案
在上一篇問題解決中:python OSError: [Errno 24] Too many open files | HTTPConnectionPool(host=‘‘, port=80): Max retries e
有提到修改本地進程最大文件數來避免Max retries exceeded with url 報錯,也談到如果請求api端有請求數量限制,仍然是拉取不到結果的。這時我們就要限制我們請求的頻率了。
下面有三個常見的方法:
1、增加重試連接次數:
requests.DEFAULT_RETRIES = 5
2、關閉多余的鏈接:
默認的http connection是keep-alive的,在post請求中,header中有這樣一個字段:Connection,我們將其置為’close’
http是一個無狀態的面向連接的協議。
http無狀態:無狀態協議是指http協議本身對于事務處理沒有記憶功能,服務器不知道瀏覽器的狀態。通俗的即使你登錄了,去訪問同一個網站的不同網頁,服務器都不會知道你是誰,如果需要記錄登錄用戶的信息,用戶操作,用戶行為等數據需要使用cookie或session來存儲。
keep-alive:從HTTP/1.1起,瀏覽器默認都開啟了Keep-Alive,保持連接特性,客戶端和服務器都能選擇隨時關閉連接,則請求頭中為connection:close。簡單地說,當一個網頁打開完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一條已經建立的TCP連接。但是Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的服務器軟件(如Apache)中設定這個時間。
誤解:無狀態不代表HTTP不能保持TCP連接,更不能代表HTTP使用的是UDP協議(無連接)。即使http在無狀態下,只要客戶端和服務器的頭部信息connection:keep-alive,則在有效期內他們使用同一條TCP連接。
3、請求時增加緩沖延時
由于我這里是多線程進行post請求,總共有2744個線程。這里進行分批次的發請求,發完一次sleep一段時間:
keep alive 與close使用場景
1、當你的Server內存充足時,KeepAlive =On還是Off對系統性能影響不大。
2、當你的Server上靜態網頁(Html、圖片、Css、Js)居多時,建議打開KeepAlive 。
3、當你的Server多為動態請求(因為連接數據庫,對文件系統訪問較多),KeepAlive 關掉,會節省一定的內存,節省的內存正好可以作為文件系統的Cache(vmstat命令中cache一列),降低I/O壓力。
PS:當KeepAlive =On時,KeepAliveTimeOut的設置其實也是一個問題,設置的過短,會導致Apache 頻繁建立連接,給Cpu造成壓力,設置的過長,系統中就會堆積無用的Http連接,消耗掉大量內存,具體設置多少,可以進行不斷的調節,因你的網站瀏覽和服務器配置 而異。
參考:
解決Max retries exceeded with url的問題
轉:Connection: close和Connection: keep-alive有什么區別?
總結
以上是生活随笔為你收集整理的Max retries exceeded with url 解决方案的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 黄体酮胶囊多少钱啊?
- 下一篇: 地下城与勇士DNF怎么合天空几率大