我编写了以下代码来大幅优化在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)
答案 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。这将使它变慢。