Scrapy效能分析

標籤：

之前講過（這裡），當Scrapy正常運行時，下載器是瓶頸。在這種情況下，你會看到調度器中有一些請求，下載器中的並發請求數目已經達到最大值，而scraper（爬蟲和pipeline）的負載比較輕，正在處理的Response對象數目也不會一直增長。

主要有三個設定項來控制下載器的容量：CONCURRENT_REQUESTS，CONCURRENT_REQUESTS_PER_DOMAIN和
CONCURRENT_REQUESTS_PER_IP。第一個設定項提供了一個粗略的控制，無論如何不會有超過CONCURRENT_REQUESTS數目的請求被並發下載。在另一方面，如果你的目標網域名稱只是一個或者少數的幾個，那麼CONCURRENT_REQUESTS_PER_DOMAIN可能就會提供對並發請求數目的更進一步的限制。不過如果你設定了CONCURRENT_REQUESTS_PER_IP，那麼CONCURRENT_REQUESTS_PER_DOMAIN就會被忽略，這時的限制會是針對每個IP的。在很多網域名稱都反射一個伺服器的時候，這會幫你避免過度地訪問遠程伺服器。

為了使我們的分析工作簡單一點，我們把CONCURRENT_REQUESTS_PER_IP保持為預設值（0），這樣就禁用了對每個IP的限制，並且把CONCURRENT_REQUESTS_PER_DOMAIN設定成一個很大的值（1000000） 。這樣的設定實際上就是禁用了這些限制，這樣下載器的並發請求數目就只由CONCURRENT_REQUESTS來控制了。

我們希望系統的輸送量決定於它下載一個頁面所花費的平均時間，包括遠程伺服器響應的時間和我們自己的系統（Linux，Twisted/Python）的延遲時間。再把啟動時間和關閉時間也算進來，包括得到一個Response對象的時間與它的Item從pipeline中處理完畢的時間之差，以及程式啟動後到得到第一個Response對象之間的延遲。

總的來說，如果你需要完成一個共有N個請求的作業，並且爬蟲已經被調整好了，那麼程式就可能在時間內運行完。

對於上面公式的大多數參數我們都沒法控制它們，我們可能通過使用一個效能比較好的伺服器來稍稍控制一下和（這個參數甚至都不值去控制它，因為每次運行我們一般只啟動和關閉程式一次）。除了這些對一個工作量為N個請求的作業的稍微改善，所有我們能調整的只是CONCURRENT_REQUESTS的值，這個主要取決於我們要多頻繁地訪問遠程伺服器。如果我們把它設定成一個很大的值，那麼在某個時候，我們的伺服器的CPU和遠程伺服器的承受能力都會達到一個飽和狀態，也就是說，那個時候的值會急劇上升，因為目標網站會限制我們的訪問或者禁止掉我們的IP、或者我們直接把目標網站搞癱瘓了。

下面運行一個實驗。我們分別使用和這兩個條件為變數來運行爬蟲：

$ for delay in 0.125 0.25 0.50; do for concurrent in 8 16 32 64; do    time scrapy crawl speed -s SPEED_TOTAL_ITEMS=2000 -s CONCURRENT_REQUESTS=$concurrent -s SPEED_T_RESPONSE=$delaydone; done

下面是結果：

組織一下上面的那個方程，可以得到一個簡單的形式，而x = N/CONCURRENT_REQUESTS。用最小二乘法和表格中的資料，可以得到和。值很小可以忽略，而從開始到得到第一個響應的時間雖然比較長但是對於數千的URL以及很長的已耗用時間就不足為慮了。下面是計算輸送量的一個公式：。

Scrapy效能分析