比較多處理與扭曲的問題

Question

得到了我要解析網站的情況。每個網站必須有它自己的「解析器」，並可能是它自己的方式處理餅乾/等。

我試圖讓我的頭，這將是一個更好的選擇。

選擇I： 我可以創建一個多處理函數，其中（masterspawn）應用程序獲取輸入url，並且它跨越masterspawn應用程序中的進程/函數，然後處理所有的設置/讀取/解析該網頁/網址。

這種方法將有一個主應用程序運行，並反過來創建內部函數的多個實例。應該快，是/否？

選擇II： 我可以創建一個「Twisted」類型的服務器，它基本上與Choice I做同樣的事情。不同之處在於使用「Twisted」也會帶來一些開銷。我試圖評估扭曲，關於它是一個「服務器」，但我不需要它來執行URL的抓取。

選擇三： 我可以使用scrapy。我不想走這條路，因爲我不想/不需要使用scrapy似乎有的開銷。正如我所說，每個目標網址需要自己的解析功能，以及處理餅乾...

我的目標是基本上有「架構」的解決方案分佈在多個框，其中每個客戶端框接口與一個主服務器分配要解析的URL。

感謝在這個任何意見..

-Tom

Answer 1

有兩個方面對這個問題：併發和分佈。併發性：Twisted或multiprocessing將完成同時處理讀取/解析作業的工作。我不知道你的「扭曲的開銷」的前提是從哪裏來的。相反，多處理路徑會招致更多的開銷，因爲必須產生（相對重的）OS過程。 Twisteds處理併發的方式要輕得多。

分佈：多處理不會將您的讀取/解析作業分發到不同的框。扭曲可以做到這一點，例如。使用AMP協議建設設施。

我不能評論scrapy，從來沒有使用它。

Answer 2

對於這個特定的問題，我會使用多處理技術 - 它使用簡單，易於理解。你並不特別需要扭曲，所以爲什麼要承擔額外的複雜性。

另一個可能需要考慮的選項是：使用消息隊列。讓主人將URL放入隊列（例如，beanstalkd,resque, 0mq），並讓工作進程獲取URL並處理它們。您將獲得併發和分發：您可以根據需要在儘可能多的機器上運行工作。