12

（问题已编辑 b/c 我已经意识到它涉及文件类型）

这个文件是 20kb。服务持续时间 > 1 秒。

http://www.adrenalinemobility.com/js/ss-symbolicons.js

这是带有 .css 作为扩展名的相同文件：

http://www.adrenalinemobility.com/js/ss-symbolicons.css

它的服务速度快了将近 1 秒。

这是我的 app.yaml：

application: adrenaline-website
version: 1
api_version: 1
runtime: python27
threadsafe: true

libraries:
- name: jinja2
  version: latest

handlers:
- url: /favicon\.ico
  static_files: assets/favicon.ico
  upload: assets/favicon\.ico

- url: /css
  static_dir: assets/css

- url: /img
  static_dir: assets/img

- url: /js
  static_dir: assets/js

- url: /.*
  script: web.APP

我也试过这static_files条线（在 /js 处理程序之前），它也很慢：

- url: /js/ss-symbolicons.js
  static_files: assets/js/ss-symbolicons.js
  upload: assets/js/ss-symbolicons.js

我观察到的方式：

  • Chrome、Firefox（都在 Linux 上）——来自硅谷的 DSL 连接
  • wget、curl 等来自该机器。
  • 从伊利诺伊大学的高速服务器远程 wget 和 curl
  • 远程 Web 测试服务，如webpagetest（见下文）：

这是一个说明这个问题的网页测试瀑布图 - 请注意一个文件有一个巨大的 TTFB：http ://www.webpagetest.org/result/131101_ZQ_ZGQ/1/details/

如果我手动将 mime_type 设置为text，那么它会很快。application/javascript, application/x-javascript,text/javascript都很慢。目前，如果您想测试，这些文件在没有手动指定的 mime 类型的情况下提供服务。

jchu 注意到的更多信息：

慢版本服务于：Content-Length: 19973快速版本服务于：Transfer-Encoding: chunked

更多细节：

我通常得到 server 74.125.28.121。reddit 上的某个人获得了服务器173.194.71.121，并且似乎它们之间的服务速度甚至还可以。所以也许它取决于服务器/位置？

关于这个问题的另一篇文章

这是一个包含两个文件请求的完整 curl 日志的 pastebin

这是另一个pastebin，其中仅包含来自每个文件的十个请求的时间信息，处于紧密循环中

4

2 回答 2

3

将 mime_type: text 添加到您的 JavaScript 静态资源中。

需要研究假定的 mime_type 是什么，对于 text 与其他 mime 类型有什么巧妙的技巧......

于 2013-11-01T18:48:36.350 回答
2

我一直在看到同样的行为。

GAE 对这些 javascript 文件有一些奇怪的边缘缓存行为。在第 4 次或第 5 次连续请求之后，响应时间显着提高（某种类型的 gzip 压缩内容的边缘缓存开始起作用）。在我的实验中，它从大约 1.2s -> 190ms

我已经能够在 3 个 GAE 应用程序中始终如一地重现这一点。如果您使用 Chrome，您可以转到 DevTools 设置并禁用缓存（在 DevTools 打开时）。重新加载页面几次将使您的 javascript 传输时间降低到合理的数字。

谷歌的边缘缓存可能有一些逻辑，它确定它不会打扰缓存 gzip 压缩的 js 文件，直到它们被足够频繁地请求。这似乎鼓励您编写一个脚本来不断下载您的 js 文件，以确保它们的下载速度快几百毫秒。我怀疑边缘缓存足够聪明，一次只能缓存一个区域。

于 2013-11-12T21:23:52.500 回答