Flask在Windows環境下的部署

背景

因爲目前在用的Flask項目涉及到一部分依賴Windows的處理，還沒法遷移到linux平臺，那麼在windows環境下，要怎麼部署呢？

思路

根據Flask官網介紹，因爲Flask內置的服務器性能不佳，推薦的主要的部署方式有以下幾種：

• mod_wsgi (Apache)

• 獨立 WSGI 容器

  • Gunicorn
  • Tornado
  • Gevent
• uWSGI
• FastCGI
• CGI

上述這些部署方式，僅Tornado是支持在windows狀況下部署的，配合上Nginx能夠達到比較好的效果。可已參考Nginx與tornado框架的併發評測。

可是在實際使用中發現，tornado 的穩定性雖然很高，可是在tornado上部署Flask，並不會有異步的效果。實際上仍是單進程阻塞運行的，即便在Flask中配置了threaded = True也沒法實現多線程使用。

Flask多線程狀況

配置啓用多線程：

# manage.py
from flask_script import Server

server = Server(host="0.0.0.0", threaded=True)

在Flask中配置兩條測試路由

import time
@main.route('/test')
def maintest():
    return 'hello world'
    
@main.route('/sleep')
def mainsleep():
    time.sleep(60)
    return 'wake up'

先用瀏覽器訪問\sleep：

隨即馬上訪問\test:

可見兩次訪問是不一樣的線程處理的，不會出現堵塞的狀況。

tornado + Flask多線程狀況

使用tornado託管：

from tornado.wsgi import WSGIContainer
from tornado.httpserver import HTTPServer
from tornado.ioloop import IOLoop
from yourapplication import app

http_server = HTTPServer(WSGIContainer(app))
http_server.listen(5000)
IOLoop.instance().start()

先用瀏覽器訪問\sleep：

隨即馬上訪問\test:

能夠發現，雖然tornado框架是支持異步的，可是因爲實際上後臺的處理是同步的，從而沒法實現異步的處理的效果。若是想後臺的處理也異步，則須要直接使用tornado來開發。

那麼爲何使用tornado來託管flask呢？

Tornado 是一個開源的可伸縮的、非阻塞式的 web 服務器和工具集，它驅動了 FriendFeed 。由於它使用了 epoll 模型且是非阻塞的，它能夠處理數以千計的併發固定鏈接，這意味着它對實時 web 服務是理想的。把 Flask 集成這個服務是直截了當的

根據官網描述，其實也是爲了彌足flask自帶服務器不穩定的問題。

Flask高併發下的表現

使用tsung進行壓測，壓力500：

Name	highest 10sec mean	lowest 10sec mean	Highest Rate	Mean Rate	Mean	Count
connect	34.30 msec	31.91 msec	506 / sec	356.60 / sec	33.19 msec	103908
page	0.42 sec	0.29 sec	505 / sec	356.32 / sec	0.39 sec	103782
request	0.42 sec	0.29 sec	505 / sec	356.32 / sec	0.39 sec	103782
session	1mn 24sec	10.64 sec	11.4 / sec	1.21 / sec	14.24 sec	362

Code	Highest Rate	Mean Rate	Total number
200	505 / sec	356.32 / sec	104792

Name	Highest Rate	Total number
error_abort	0.5 / sec	1
error_abort_max_conn_retries	11.7 / sec	362
error_connect_econnrefused	58.6 / sec	1667

可見，在500的併發下，效果不佳，有不少的連接拒絕。

Flask + Nginx在高併發下的表現

• 使用tsung進行壓測，壓力500：

Name	highest 10sec mean	lowest 10sec mean	Highest Rate	Mean Rate	Mean	Count
connect	0.20 sec	30.95 msec	1810.5 / sec	626.43 / sec	0.11 sec	189853
page	0.68 sec	0.17 sec	1810.1 / sec	625.72 / sec	0.40 sec	189581
request	0.68 sec	0.17 sec	1810.1 / sec	625.72 / sec	0.40 sec	189581

Code	Highest Rate	Mean Rate	Total number
200	906.4 / sec	196.08 / sec	60689
502	1443.9 / sec	430.02 / sec	129006

Name	Highest Rate	Total number
error_abort	0.5 / sec	1

狀況差很少，Flask服務器表現還算穩定，那麼嘗試增長後臺Flask服務器數量（經過多端口實現）：

python manage.py runserver --port=8001
python manage.py runserver --port=8002
python manage.py runserver --port=8003
python manage.py runserver --port=8004

• 使用tsung進行壓測，壓力500，4個Flask服務器：

Name	highest 10sec mean	lowest 10sec mean	Highest Rate	Mean Rate	Mean	Count
connect	0.18 sec	32.57 msec	3510.1 / sec	639.92 / sec	0.11 sec	195154
page	0.49 sec	85.30 msec	3512.1 / sec	639.07 / sec	0.35 sec	194856
request	0.49 sec	85.30 msec	3512.1 / sec	639.07 / sec	0.35 sec	194856

Code	Highest Rate	Mean Rate	Total number
200	3510.1 / sec	639.50 / sec	194986

Name	Highest Rate	Total number
error_abort	0.333333333333333 / sec	1

這個效果妥妥的。

• 使用tsung進行壓測，壓力1000，4個Flask服務器：

Name	highest 10sec mean	lowest 10sec mean	Highest Rate	Mean Rate	Mean	Count
connect	0.20 sec	32.63 msec	2983.8 / sec	492.94 / sec	98.56 msec	150793
page	0.57 sec	90.00 msec	2976.4 / sec	491.31 / sec	0.40 sec	150275
request	0.57 sec	90.00 msec	2976.4 / sec	491.31 / sec	0.40 sec	150275

Code	Highest Rate	Mean Rate	Total number
200	2981.4 / sec	488.92 / sec	149556
502	92.5 / sec	4.02 / sec	925

Name	Highest Rate	Total number
error_abort	0.333333333333333 / sec	1

開始有一些502的超時錯誤了。

• 使用tsung進行壓測，壓力1000，4個tornado服務器：

Name	highest 10sec mean	lowest 10sec mean	Highest Rate	Mean Rate	Mean	Count
connect	0.18 sec	86.24 msec	2052.1 / sec	693.82 / sec	0.14 sec	208786
page	0.52 sec	0.24 sec	2060.7 / sec	693.34 / sec	0.45 sec	208606
request	0.52 sec	0.24 sec	2060.7 / sec	693.34 / sec	0.45 sec	208606

Code	Highest Rate	Mean Rate	Total number
200	2056.6 / sec	693.67 / sec	208703

在併發1000的狀況下，是否使用tornado託管Flask效果差很少。

結論

根據上述測試，直接使用Flask服務器的話，因爲併發處理較弱，會有各類超時或者鏈接拒絕的錯誤。經過搭配Nginx來進行緩衝，經過增長後端服務器數來提供併發處理量。

因此最終選擇了Nginx+後臺4個Flask服務器的方式。因爲目前Flask項目全體用戶只有幾千，目前併發狀況很低，該方式徹底知足使用。

若是在更大型項目中，併發上萬，建議仍是考慮想辦法遷移至Liunx環境，經過官方建議的方式部署。