爬蟲協程比線程爬取速度更快？

先作個小示例，不用廢話談理論，沒有實踐的空談都是扯蛋誤導人。

這篇文章不討論線程 協程的理論。只討論標題的主題問題，爬蟲速度。

# coding=utf-8
import requests,time
count=0
urlx=  'http://www.xxsy.net/'                        #  'http://www.danmeila.com/'      http://www.sina.com.cn/                         'http://www.qingkan9.com/'  #                     #   'http://www.qingkan9.com/'
def fun(url):
    try:
        print url
        resp=requests.get(url)
        if resp.status_code!=200:
            print '***',resp.status_code

        global count
        count+=1
        print count,'  ',round((time.time()-start_time),3)

    except Exception as e:
        pass

def single_fun():
   for i in range(1000000):
       fun(urlx)

def gevent_fun():
    from gevent import monkey
    monkey.patch_all(socket=True,select=True)
    from gevent.pool import Pool
    gevent_pool = Pool(800)
    urls = [urlx for i in range(1000000)]
    gevent_pool.map(fun, urls)


def thread_fun():
    import threadpool
    thread_pool = threadpool.ThreadPool(200)
    requestsx = threadpool.makeRequests(fun, [urlx for i in range(1000000)])
    [thread_pool.putRequest(req) for req in requestsx]
    thread_pool.wait()


def funx(a,b=None):
    print a,b

if __name__=="__main__":
    start_time=time.time()
    #single_fun()     ##用什麼就把其餘的註釋掉，三種模式
    #gevent_fun()
    thread_fun()

View Code

此圖爲順序執行。

 

 

 

此圖爲協程，800併發。

 

 

 

此圖爲200線程。

 

 

上面的是以請求瀟湘書院首頁爲例。

能夠看到單個請求的同步執行，在120秒內的請求數量遠少於後二者，無論運行多少次，都是這樣的明顯少於後二者。

協程和線程相比，120秒內請求的數量很是接近，受網速的小幅波動影響可能每次運行結果都會差點（運行程序時候把其餘全部鏈接網絡的軟件關閉掉，減少干擾），但無論如何，二者都是很是接近的。

 協程能夠開啓更多，但線程開大概500以上後就會出錯，包括web性能測試工具jmter  loadrunner這些工具也都是單機併發有限的，併發設置多了同樣會報錯。我這裏開多線程用200，協程用800，儘管協程能開更多，但網速早就跑滿了。

 

線程和協程都能使網速一直跑滿。在網速一直持續飽滿的狀況下，那麼必定時間內，可以請求的字節總數都是同樣的，因此這和多線程和協程在120秒內的請求個數很是接近，基本是一致的。

瀟湘書院根本不須要開800協程，100協程早就能足夠跑滿網速了。

 

還有人說開協程能夠開100萬，線程開不了那麼多，因此協程有優點，這徹底是扯雞巴蛋，我能夠直接判斷他從沒有開過100萬協程 requets，不服的能夠把800改爲1000000看看效果，我也基本能夠95%判定他連1萬協程requests都沒有試過。沒人遇到cant watch more than 1024 sockets了嗎。只要不是響應時間差的離譜的網站，100協程早就足夠了。再加更多也不能讓120秒內請求更多的頁面。

 

速度乘以時間等於路程。

網絡使用速度*時間=總字節數。

兩個變量相同的狀況下獲得的乘積確定是同樣的。這種常識不須要再理論了。

 

 

說協程比線程爬取速度更快那麼就是扯蛋了，不要看了一點理論，就自覺得掌握了精髓，對事情妄下結論。

 

至於在一次面試中，一個創業小公司的面試官說他看網上是python多線程是假的，他爬蟲只用多進程從不用線程，這跟是無語了，爲何只是看別人說，本身不去試下。不知道那面試官是看了網上正確的東西的但他看一半理解的斷章取義了，仍是他看了網上錯誤的東西。全期望多進程是很差的，多進程佔用內存巨大，啓動多進程須要的時間特別漫長，多進程能不能使網速使用率更高，滿速了就不能再突破。

 

 

 

 

上面的實驗使用瀟湘書院作的，測試過程當中仍是用了一個很小的網站，但那個網站是很小的，響應速度超級慢，無論開了多少線程 協程都只能達到100多kb，可能人家的服務器下行帶寬就那樣。

 

測試過程當中仍是用了新浪網首頁，請求新浪網的狀況下，新浪網做爲數一數二的大網站，響應速度是很是很是好，同時一個頁面的字節數很是大，因此使用單個請求同步執行和協程 線程相比，雖然差了一點，可是遠沒有瀟湘書院那麼誇張差了10倍。也就是響應時間越大的網站，gevent threding比單線程優點才能更明顯。

 

 

搞東西，不要光理論就想固然的認爲怎麼樣了，即便是喜歡看理論的人，也須要實踐。三國時期的蜀國馬謖是怎麼死的，戰國時期的趙國馬服子是怎麼死的，熟讀兵書提及理論一套一套的，僅從一些理論就過於的認爲一件事怎麼樣，太想固然了。  馬謖 和馬服子既可憐又可恨，可憐是他們都不算大壞人，但結局都是死的很是慘，可恨是他們只喜歡紙上談兵提及東西來一套一套的的，不注重實踐，最終不只是害了本身，還連累三軍，馬謖和馬服子直接加速了蜀國和趙國的滅國之災。  若是當時不派這兩我的去帶兵打仗，隨便派個垃圾小兵作主將都不會出現輸得這麼慘。