在介紹mod_python模式之前先像大家說一下它的定義，mod_python模式標志了物件之間隱藏的規(guī)律關系，而這些物件并不必然是圖像、圖案，也可以是數(shù)字、抽象的關系、甚至思維的方式。

在這部分開始之前我也想聊聊之前我們一直在講，而且將來還一直會講下去的一個話題――狀態(tài)。 之前我們一直在討論，把用戶的狀態(tài)保存在一個集中的地方，尤其是大規(guī)模集群部署的情況下。

同樣，對于python來說亦是如此，可以說這條金科玉律不只是針對某種針對某個語言，某個框架，它應該是更高層次的一種理念。那么我們可以把狀態(tài)放到什么地方呢。目前一些流行的選擇是DB(內(nèi)存表，或實體表),memcached，或者cookie，但這幾種選擇并不是可以隨便互換的。

比如業(yè)務數(shù)據(jù)較多的情況下，放在cookie中不是很合適，因為有可能超出cookie大小的限制，那么放在memcached中，很遺憾，memcached(使用slab的情況下)中也有它自己的限制。

如果狀態(tài)數(shù)據(jù)大小跨度較大，那么丟數(shù)據(jù)的情況有可能發(fā)生，ahuaxuan很久之前在測試環(huán)境下就碰到過這種情況，由于線上memcached開得較大，所以沒有出現(xiàn)這種情況，關于這種事件發(fā)生得內(nèi)部原因在ahuaxuan的另外一篇文章中已經(jīng)有了非常詳細的描述。

那么放在DB上呢，顯然，DB的壓力也是我們需要考慮的問題之一。當然除了這些主流的選擇之外，我們其他選擇還有很多，比如memcachedb，或者timesten，或者其他等等，但是對于狀態(tài)這種東西。

尤其狀態(tài)數(shù)據(jù)比較重要的情況下，我們一定要深入研究并理解狀態(tài)數(shù)據(jù)的存儲技術，否則可能會遇到我們異想不到的情況，比如很久之前我想破頭也不會想到memcached是LRU是針對某個slab的(而且我還要插一句，LRU的時候其實并不是遍歷slab中的chunk鏈表，而且只遍歷最開始的50個數(shù)據(jù)而已，這樣做純粹是為了速度)。

目前對django來說基本上有兩種部署策略， 第一種是利用mod_python將django運行在apache進程中，還有一種是webserver+fastcgi，這兩種方式各有優(yōu)缺點。在mod_python模式中，我們的webserver必須使用apache，apache在webserver這一領域已經(jīng)獨占鰲頭很多年了，市場占有率也是遠遠的超過其他的webserver。

不過近幾年來，又崛起了幾個其他的webserver，其中比較出名的是ligttpd和nginx，它們都以高性能和低內(nèi)存消耗對apache發(fā)出了挑戰(zhàn)，而mod_python是apache的插件，使用這種方式就把我們的webserver限定在apache上了，不過還好mod_python模式也是非常的穩(wěn)定的方案了。

第二種就是webserver＋fastcgi，這里的webserver就可以隨意選擇了，大多數(shù)的webserver對提供了對fastcgi的支持，比如我們耳熟能詳?shù)膌ighttpd和nginx，而且據(jù)稱在很多情況下。FastCGI能夠提供比mod_python模式更為優(yōu)越的安全性和效能。針對小型站點，相對于Apache來說FastCGI更為輕量級。據(jù)稱qq的個人空間就是c++加fastcgi實現(xiàn)的。

哦，這樣做的優(yōu)勢在哪里呢，c++的處理速度將會非常的快，也就是說每個fastcgi處理一個請求將會非?？焖?，比如使用mod_python模式需要50毫秒，c++處理這個請求有可能只需要20毫秒（這個例子未必準確，只是為了說明fastcgi的特性）。雖然在開發(fā)上c++比較麻煩一點，不過在性能上，c++肯定是no1了，從這個例子上我們可以看到，使用fastcgi速度取決于處理一次請求的速度（廢話，哪個不是這樣）。 #t#

我們來看一下使用fastcgi的一般模式：1、WEB服務器收到客戶端的頁面請求 2、WEB服務器將這個頁面請求委派給一個FastCGI 外部進程（WEB服務器于FastCGI之間是通過socket來連接通訊的） 3、FastCGI外部進程得到WEB服務器委派過來的頁面請求信息后進行處理，并且將處理結果（動態(tài)頁面內(nèi)容）返回給WEB服務器 4、Web服務器將FastCGI返回回來的結果再轉送給客戶端瀏覽器。

對我們來說第3步是我們最需要關注的，因為第3步的速度嚴重影響著整個性能。由于fastcgi是基于進程的，所以，我們要根據(jù)我們的應用來開啟數(shù)量合適的fastcgi進程。多開了是對資源的浪費，少開了就影響性能。

這個類似我們在tomcat中開啟處理請求的thread一樣，只不過tomcat中的request handler thread在配置起來顯然更加方便，因為我們只要關注線程池中最大的可以容納的線程數(shù)，最大空閑線程數(shù)等就行了。