初次接觸Python部署問題解析
在這部分開始之前我也想聊聊之前我們一直在講，而且將來還一直會講下去的一個話題――狀態。 之前我們一直在討論，把用戶的狀態保存在一個集中的地方，尤其是大規模集群Python部署的情況下。
同樣，對于django來說亦是如此，可以說這條金科玉律不只是針對某種針對某個語言，某個框架，它應該是更高層次的一種理念。那么我們可以把狀態放到什么地方呢，目前一些流行的選擇是DB(內存表，或實體表),memcached，或者cookie。
但這幾種選擇并不是可以隨便互換的，比如業務數據較多的情況下，放在cookie中不是很合適，因為有可能超出cookie大小的限制，那么放在memcached中，很遺憾，memcached(使用slab的情況下)中也有它自己的限制。
如果狀態數據大小跨度較大，那么丟數據的情況有可能發生，ahuaxuan很久之前在測試環境下就碰到過這種情況，由于線上memcached開得較大，所以沒有出現這種情況，關于這種事件發生得內部原因在ahuaxuan的另外一篇文章中已經有了非常詳細的描述。
那么放在DB上呢，顯然，DB的壓力也是我們需要考慮的問題之一。當然除了這些主流的選擇之外，我們其他選擇還有很多，比如memcachedb，或者timesten，或者其他等等。但是對于狀態這種東西，尤其狀態數據比較重要的情況下，我們一定要深入研究并理解狀態數據的存儲技術，否則可能會遇到我們異想不到的情況。
比如很久之前我想破頭也不會想到memcached是LRU是針對某個slab的(而且我還要插一句，LRU的時候其實并不是遍歷slab中的chunk鏈表，而且只遍歷最開始的50個數據而已，這樣做純粹是為了速度)。 目前對django來說基本上有兩種Python部署策略， 第一種是利用mod_python將django運行在apache進程中，還有一種是webserver+fastcgi，這兩種方式各有優缺點。
在mod_python模式中，我們的webserver必須使用apache，apache在webserver這一領域已經獨占鰲頭很多年了，市場占有率也是遠遠的超過其他的webserver，不過近幾年來，又崛起了幾個其他的webserver，其中比較出名的是ligttpd和nginx。
它們都以高性能和低內存消耗對apache發出了挑戰，而mod_python是apache的插件，使用這種方式就把我們的webserver限定在apache上了，不過還好apache+mod_python也是非常的穩定的方案了。
第二種就是webserver＋fastcgi，這里的webserver就可以隨意選擇了，大多數的webserver對提供了對fastcgi的支持，比如我們耳熟能詳的lighttpd和nginx，而且據稱在很多情況下，FastCGI能夠提供比mod_python更為優越的安全性和效能。
針對小型站點，相對于Apache來說FastCGI更為輕量級。據稱qq的個人空間就是c++加fastcgi實現的，哦，這樣做的優勢在哪里呢，c++的處理速度將會非常的快，也就是說每個fastcgi處理一個請求將會非常快速。
比如使用python需要50毫秒，c++處理這個請求有可能只需要20毫秒（這個例子未必準確，只是為了說明fastcgi的特性），雖然在開發上c++比較麻煩一點，不過在性能上，c++肯定是no1了，從這個例子上我們可以看到，使用fastcgi速度取決于處理一次請求的速度（廢話，哪個不是這樣）。
我們來看一下使用fastcgi的一般模式：
1、WEB服務器收到客戶端的頁面請求
2、WEB服務器將這個頁面請求委派給一個FastCGI 外部進程（WEB服務器于FastCGI之間是通過socket來連接通訊的）
3、FastCGI外部進程得到WEB服務器委派過來的頁面請求信息后進行處理，并且將處理結果（動態頁面內容）返回給WEB服務器
4、Web服務器將FastCGI返回回來的結果再轉送給客戶端瀏覽器。
對我們來說第3步是我們最需要關注的，因為第3步的速度嚴重影響著整個性能。由于fastcgi是基于進程的，所以，我們要根據我們的應用來開啟數量合適的fastcgi進程。多開了是對資源的浪費。
少開了就影響性能，這個類似我們在Python部署中開啟處理請求的thread一樣，只不過tomcat中的request handler thread在配置起來顯然更加方便，因為我們只要關注線程池中最大的可以容納的線程數，最大空閑線程數等就行了。
【編輯推薦】
