3 回答
TA贡献1878条经验 获得超4个赞
对于静态文件来说,“常规” 200毫秒似乎很重要。我从我的应用程序提供了相同的“ bootstrap-sensitive.css”的静态版本,并且可以看到两种类型的回答时间:
50-100ms(大多数时间)
150-500ms(有时)
由于我与Google App Engine进行了大约50ms的ping往返,因此似乎文件通常在50ms左右的时间内提供。
我猜想150-300ms的响应时间与Google App Engine前端服务器被“冷缓存”有关。我假设从某些持久性存储中检索文件所涉及的等待时间要比前端服务器缓存中的等待时间长。
我还假设您可以使用各种前端服务器并获得零星的更高延迟。
最后,浏览器的总体感知延迟应通过以下方式近似估算:(tc)往返+前端服务器上的tcp / http排队/缓冲+文件服务应用程序时间(如google app日志中所示)+传输时间文件。
如果前端服务器未过载且文件较小,则延迟应接近ping +服务时间。
在我的情况下,50ms(ping)+ 35ms(服务)= 85ms,非常接近我在浏览器中看到的95ms。
最后,如果您的应用程序正在处理大量请求,则它们可能会排队,从而导致延迟在应用程序日志中不可见。
TA贡献1845条经验 获得超8个赞
为了进行比较,我使用tools.pingdom.com测试了一个网站
Pingdom 报告的加载时间为 218ms
这是日志的结果:
2013-02-11 22:28:26.773 /stylesheets/bootstrap.min.css 200 35ms 45kb
238ms
由Pingdom和2ms
日志产生的另一项测试。
因此,我想说您183ms
看来比较好。有很多因素在起作用:
您到服务器的位置
服务资源的服务器是否过载?
您可以尝试使用Go实例而不是App Engine的静态文件服务器来提供文件。我前段时间对此进行了测试,结果偶尔会更快,但是速度却不一致。由于App Engine实例仅限于10个并发请求,因此在负载下,响应时间也有所增加。更不用说您需要支付实例时间的费用。
- 3 回答
- 0 关注
- 197 浏览
添加回答
举报