測試例子

#!/bin/env /usr/local/bin/python

import web 

web.config.debug = False

urls = ('/(.*)', 'hello')
app = web.application(urls, globals())

class hello:    
    def GET(self, name):
        if not name: 
            name = 'World'
            return 'Hello, ' + name + '! fuck the hello'

if __name__ == "__main__":
    app.run()
 

ps：貌似是從官網直接copy的demo，自己猥瑣的修改了一下。

測試工具
apache自帶的著名ab，雖然我認為它不怎麼樣，至少感覺沒它名聲那麼好。測試引數如下：

ab -n 10000 -c 100 http://127.0.0.1:1988/  

web.py效能

直接利用web.py內建的web server來啟動這個hello word服務，啟動時將標準輸出和標準錯誤重定向到/dev/null以此減少IO的消耗。benchmark如下圖：

web.py程式預設啟動雖然是多執行緒的(這個在/proc/pid裡面是可以看到的)，但由於python多執行緒實現上的鎖問題，在併發上面一直沒有顯著的效果，所以這裡的benchmark有點慘不忍睹，至少讓研究高併發伺服器的會很不滿意。16核的cpu放在那裡一動不動的，好可惜啊。

nginx + spawn-fcgi + flup + web.py效能

這裡nginx沒有做任何調優，基本屬於預設配置，除了加入fastcgi相關指令外。web.py是利用spawn-fcgi啟動了32個程序，其實和16個程序沒有多大的區別。測試主機是8核、超執行緒到了16核；記憶體對本次測試不會構造影響。benchmark如下圖：

ps：採用這個的一個架構，效能有了明顯的提升了，qps是單web.py的8倍。效能的提升主要就是在python的多程序複用了多核cpu。16個核都跑到了70%-80%，基本屬於跑滿了；load也達到了50-60了。24G記憶體的測試主機，記憶體不是瓶頸。這個結果的優化空間應該也不會太大了，畢竟cpu幾乎跑滿了負載也上來了，cpu終究成為了瓶頸。

總結一點

高效能伺服器的設計可以採用多執行緒或多程序，最大的複用cpu。cpu就放在那裡，不用白不用。

錯誤小記

利用spawn-fcgi啟動web.py的測試程式時，總是丟擲如下錯誤， 最後發現居然是-f 選項指定的檔案沒有采用絕對路徑，spawn-fcgi的使用者體驗太低了。

spawn-fcgi: child exited with: 127