Tag Archives: Gevent

這篇文章是要大略介紹一下coroutine和Python的相關應用的函式庫gevent，在介紹coroutine前我們先來點情境，因為目前常見的coroutine應用都是在網路程式上，因此我們得先建立一些網路框架的模形再介紹coroutine會比較容易懂 不同的網路框架模型 網路隨著時代發展，已經成為現代生活中越來越重要的重要的基礎，而做為提供這些服務的伺服器，負載的連線也越來越多，因此網路程式的軟體、硬體架構也一直在演變，才有辦法承載越來越多的連線數量，有人希望在一台機器能夠同時處理1萬個連線以上，所以提出C10K問題，並且之後有不少新的的技術來達成這個目標，而在此我們只專注在於軟體的架構上，首先介紹最簡單的架構 阻塞式單一行程 這樣的網路程式非常的簡單，只有一個迴圈，單一個行程，處理完一個要求後才繼續處理下一個，理所當然這樣的效能非常差，因為連線在完成前其它的連線都無法被處理，現代的伺服器已經很少看見這樣的架構，但因為優點是簡單，如果沒有什麼大量同時連線要處理，其實這樣的架構就很足夠 阻塞式多行程 因為既然單一行程只能同時處理一個請求，那很簡單的想法就是每個請求開一個行程去處理，如此一來就能同時處理更多的請求，但是這樣做有缺點，行程的copy如果是fork的話，有os paging system在成本上其實還好，但是還是有，而且越多的連線就表示需要越多的context-switch，當連線量多到一定程度時，可能大部份的CPU時間都在忙著進行context-switch，如此一來這樣的架構在此情況下是沒有效率的，但是優點是寫伺服器的部份事實上和寫單一行程阻塞式不會差太多，一樣簡單好寫 阻塞式多行程多執行緒 除了多行程多阻塞式，有些程式為了減少process copy的成本，或是其它的考量，會在多個行程上開多個執行緒來處理請求，也有可能是單行程多執行緒，但是基本上和上面這幾種都沒有太大的差別，而引進了執行緒帶來了一些額外的問題，dead lock、race condition等等，當不同的執行緒如果在一起有共同的東西要處理，這些常見的同作問題就會出現，使得程式得寫得更小心 非阻塞式事件驅動 為了解決上面提到多行程和多執行緒等所帶來的問題，有一種做法是只有單一主要的迴圈來檢查有無網路IO的事件發生，再來決定要怎樣處理，這樣的好處在於省掉了context-switch、process copy等等成本，也不會有dead lock、race condition等問題，但缺點在於程式的部份會變複雜，因為當你一件事件被觸發，有事情還沒做完，你就得記下目前狀態，再下次事件觸發時再依先前的狀態來決定接下來要做什麼，不像上面是線性的程式執行那樣直觀，Twisted就是這樣的網路框架 非阻塞式Coroutine 那你或許會想，有沒有可能我們能有事件驅動的好處，和阻塞式那樣的直觀好處呢? 答案或許就是Coroutine，基本上它的本質也是事件驅動，只有單一的迴圈在檢查事件的發生，但是加上了coroutine的概念，而Gevent就是這樣的函式庫 Coroutine 講了這麼多次coroutine，我相信大部份的讀者可能還是不懂這到底是什麼鬼東西，對於大部份程式設計師而言這應該都算是較陌生的名字，對我而言，在一開始這也是個令人困惑的名詞，但事實上只要理解以後就會發現coroutine不是這麼的難懂，用簡單的一句話來說Coroutine，就是可以暫時中斷，之後再繼續執行的程序，我們來看一個例子，事實上Python就有最基礎的Coroutine，也就是generator # -*- coding: utf8 -*- def foo(): for i in range(10): # 丟資料並且把主控權交給呼叫者 yield i print … Continue reading →