我想我确切地知道发生了什么. TL; DR它在服务器端实际上并不慢,我只是被Newrelic报告的响应时间误导了！
我尝试在@AllanAnderson建议的dotCloud沙箱上运行相同的代码.我首先创建了一个简化的测试用例：一个简单的HTML表单,其中一些隐藏字段预先加载了大约900KB的数据,以及一个除了从request.form字典读取之外什么都不做的视图函数,并测量每次访问所用的时间了time.time().
在Heroku上,结果看起来像这样：
5.87100 seconds: read field "p1": 786432 bytes
0.00019 seconds: read field "p2": 131072 bytes
0.00003 seconds: read field "p3": 12288 bytes
0.00001 seconds: read field "p4": 1024 bytes
在dotCloud上：
0.00096 seconds: read field "p1": 786432 bytes
0.00019 seconds: read field "p2": 131072 bytes
0.00003 seconds: read field "p3": 12288 bytes
0.00001 seconds: read field "p4": 1024 bytes
但是,这两个测试似乎在我的浏览器中占用了相同的时间……到现在为止,你可能已经猜到了这个“问题”的真正答案. 🙂
事实证明,Heroku上的gunicorn在收到标题后立即执行视图功能,并且第一次访问request.form被阻止,直到收到其余的请求.因此,Newrelic看到了所有这些非常慢的响应时间,这实际上只是通过糟糕的网络连接上传POST数据的结果. dotCloud的设置显然只是等待直到收到整个请求.
这使得Newrelic的指标不那么有用,但实际上并不是最终用户体验的问题.
9731
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
