測試環境:

伺服器配置: 4 x Intel(R) Xeon(R) CPU E5405  @ 2.00GHz， 4G記憶體, 作業系統: CentOS 5.3 x86_64

nginx前端 + 4 tornado(0.2) web process

測試場景:

http get請求，伺服器端直接返回”hello world”

程式碼及nginx配置:

main.py:

from tornado.httpserver import HTTPServer
from tornado.ioloop import IOLoop
from tornado.web import RequestHandler, Application, authenticated

#from rockps.auth import AuthHandler

class MainHandler(RequestHandler):
def get(self):
self.write(“hello world”)

settings = {
}

application = Application([
(r”/”, MainHandler),
], **settings)

if __name__ == “__main__”:
http_server = HTTPServer(application)
http_server.listen(8081)
IOLoop.instance().start()

nginx.conf:

error_log /var/nginx_error.log;
pid /var/run/nginx.pid;

events {
worker_connections 51200;
use epoll;
}

http {
# Enumerate all the Tornado servers here
upstream frontends {
server 127.0.0.1:8081;
server 127.0.0.1:8082;
server 127.0.0.1:8083;
server 127.0.0.1:8084;
}

#include /etc/nginx/mime.types;
default_type application/octet-stream;

access_log /var/log/nginx/access22.log;

keepalive_timeout 65;
proxy_read_timeout 200;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
gzip on;
gzip_min_length 1000;
gzip_proxied any;
gzip_types text/plain text/html text/css text/xml
application/x-javascript application/xml
application/atom+xml text/javascript;

# Only retry if there was a communication error, not a timeout
# on the Tornado server (to avoid propagating “queries of death”
# to all frontends)
proxy_next_upstream error;

server {
listen 8085;

# Allow file uploads
client_max_body_size 50M;

location ^~ /static/ {
root /var/www;
if ($query_string) {
expires max;
}
}
location = /favicon.ico {
rewrite (.*) /static/favicon.ico;
}
location = /robots.txt {
rewrite (.*) /static/robots.txt;
}

location / {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_pass http://frontends;
}
}
}

測試結果:

點選率可以超過7000，但後面再加使用者開始往下掉，請求開始出錯，最合適的時候大概3500個使用者

持續執行後，連線數穩在1萬。

Python的web開發框架這麼多，實在眼花繚亂，Tornado相比來說還算個新東西，文件也很少，是哪些特性吸引了知乎工程師呢

Tornado非同步非阻塞的I/O模型的確讓人耳目一新，Tornado的優勢主要在於對大量Comet長輪詢連線的維護上。這也是FriendFeed開發Tornado的原因—–因為FriendFeed需要實時更新Timeline，而Comet又是目前最好，最流行的方法。由於知乎也有大量長輪詢連線需要維護，所以選擇Tornado也就在情理之中了。
但是我們也要看到，Tornado不是萬金油，由於Tornado的WEB伺服器為單執行緒，一個Request如果阻塞了I/O，那麼這個程序將一直掛起，既無法接受新的Request，也無法Finish正在阻塞的其它Request。雖然可以Spawn多個Tornado程序，但是程序這種重量級的東西，Spawn太多會消耗大量的記憶體資源。這種感覺很像PHP的FastCGI程序那種味道。所以如果是會阻塞I/O的Request一般都是利用Tornado內建的非同步HTTP Client交給其它動態後端來做。
所以Tornado在生產中一般前面都要包一層nginx做反向代理，用nginx來做靜態檔案等大資料量的I/O操作。Tornado的I/O時間實在是太金貴了，在這上面耗不起。
@劉連響 提到的那個測試（kb.cnblogs.com/a/1591500/）在實際應用中並沒有什麼價值。因為實際應用中必然有邏輯處理，邏輯處理必然要阻塞I/O，這會使Tornado的效能大幅下降。測試可在網頁程式碼^{self.write(“hello world”)}前加一句^{time.sleep(0.01)}，假設每個Request阻塞I/O 10毫秒，再測試一下效能。
至於你提到的Tornado文件少的問題，我覺得你可以抽空閱讀一下Tornado的程式碼，畢竟是個輕量級框架，程式碼不多，但是註釋卻很詳細，很容易看懂。請記住，程式碼永遠是最好的文件