Linux / Flask和Windows / Flask之间的速度差异很大

时间:2014-02-06 16:28:08

标签: python windows jboss flask

我编写了以下代码来大幅优化在Linux下工作的开发人员的开发周期......它的作用是,它直接从磁盘提供静态内容,并且只将REST-ful请求转发给他们的运行JBOSS的一个例子。

换句话说......

  • 而不是从浏览器中点击http://127.0.0.1:8080/APPNAME,而不是在本地运行的JBOSS ...
  • 他们点击了http://127.0.0.1:4040/APPNAME - 只能说到JBOSS 对于RESTful Web服务,并直接从磁盘提供静态内容(.html / .css / .js)。

这使得他们的开发周期大大加快,因为在将他们的TypeScript代码编译为JavaScript之后,他们只是在浏览器上点击“刷新”,并且 tiny forwarder提供新版本的文件。他们不需要执行完整的JBOSS构建,生成包含更新的.js的.ear,并部署到他们的本地JBOSS。

例如一个或两个文件编辑,这提供2个(可能是3!)订单的更快速的测试 - 它基本上是“编译TypeScript,在浏览器中重新加载”。

然后我尝试使用在64位Windows下工作的开发人员,安装本机64位Windows Python,然后安装setuptools,然后安装'easy_install flask'。

......在我的绝望中,发现该脚本在Windows下运行速度慢了20-30倍!

这是Flask的限制,还是我能做些什么?

感谢您的帮助。

代码:

# Detection of some global variable content from environent and config files
...

# And the tiny forwarder:
from flask import (Flask, make_response, request, send_from_directory)

appMain = Flask(
    __name__, static_url_path='/'+g_appName, static_folder=g_staticPath)
appMain.config['MAX_CONTENT_LENGTH'] = 1024 * 1024


@appMain.route(
    "/"+g_appName+"/",
    methods=['GET', 'POST'])
def index():
    return send_from_directory(g_staticPath, 'index.html')


@appMain.route(
    "/"+g_appName+"/rest/<unused_entityName>/<unused_endpoint>",
    methods=['GET', 'POST'])
def genericForwarder(unused_entityName, unused_endpoint):
    request.url = request.url.encode('ascii')
    url = "http://127.0.0.1:8080/" + \
          re.sub(r'^http.*:4040/', '', request.url)
    try:
        print g_green + "\nRedirecting:\n    " + g_normal + request.url,
        print g_green + "\nto:\n    " + g_normal + url,

        method = request.method
        cookieData = ""
        prefix = ""
        for key, value in request.cookies.items():
            cookieData += prefix + key + '=' + value
            prefix = "&"

        print g_yellow + "\nCookies >>> " + g_normal + cookieData

        handler = urllib2.HTTPHandler()
        opener = urllib2.build_opener(handler)
        headers = {}
        headers['Content-Type'] = 'application/json'
        if cookieData:
            headers['Cookie'] = cookieData
        r = urllib2.Request(url, headers=headers, )
        r.add_data(request.data)
        r.get_method = lambda: method
        #if 'zekmSave' in request.url:
        #    import ipdb
        #    ipdb.set_trace()

        f = opener.open(r)
        response = f.read()
        resp = make_response(response, 200)
        respCookies = f.headers.get('set-cookie', '')
        print g_cyan + "Cookies <<< " + g_normal + respCookies
        if respCookies:
            resp.headers['Set-Cookie'] = respCookies
        resp.headers['Content-Type'] = 'application/json'
    except Exception, e:
        message = e.fp.read()
        print g_red, "Exception:", str(e), g_normal, "\n"
        print g_yellow, e.code, message, g_normal
        resp = make_response(message, e.code)
    return resp


if __name__ == "__main__":
    appMain.run(debug=True, host='127.0.0.1', port=4040)

2 个答案:

答案 0 :(得分:0)

我很想用简单的&#34; Windows糟透了&#34; 来回答我自己的问题,但这太过于一般的格言。我只能猜测速度差异与Windows&#34;分叉&#34;的冰川产生速度有关。进程(比任何UNIX操作系统慢1-2个数量级) - 所以如果Flask遵循UNIX Web服务器中常用的fork / exec模式,那么可以解释这个问题。

我是如何应对的?

简单:我更新了我的构建脚本,这样一旦构建完成,它会自动找到JBoss&#34;爆炸的本地文件夹&#34;部署的.ear($ JBOSS_HOME / standalone / tmp / vfs / ...)然后rsync是该文件夹中新生成的.js / .css / .html文件。值得庆幸的是,即使在Windows下,CygWin的rsync工作也足够快,即使对于我的Windows锁定的兄弟,构建周期也是即时的:重建,然后在他们的浏览器中使用Ctrl-R。

答案 1 :(得分:0)

除非你安装了visual studio,否则Flask模块不会被编译为C并且在Windows上将是纯Python。这将使它变慢。