App Engine taking Far Longer (> 1 sec) to serve st

Question

(Question edited b/c I have realized it involves file type)

This file is 20kb. It is consistently taking > 1 second to serve.

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

Here is the same file with .css as it's extension:

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

It serves almost 1 whole second faster.

Here is my 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

I've also tried this static_files line (before the /js handler), and it was slow too:

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

Ways I have observed this:

• Chrome, Firefox (both on Linux) - from a DSL connection in Silicon Valley
• wget, curl, etc from that machine.
• Remotely wget and curl from a high-speed server at the University of Illinois
• Remote web testing services like webpagetest (see below):

Here's a webpagetest waterfall graph that illustrates this problem - notice the one file has a huge TTFB: http://www.webpagetest.org/result/131101_ZQ_ZGQ/1/details/

If i manually set the mime_type to text, then it goes fast. application/javascript, application/x-javascript, text/javascript are all slow. Currently those files are serving without manually specified mime-type if you wish to test.

Some more info, as noticed by jchu:

The slow version serves with: Content-Length: 19973 and the fast version serves with: Transfer-Encoding: chunked

Still more details:

I usually get server 74.125.28.121. Someone on reddit got server 173.194.71.121 and it seems to have even serving speeds between them. So maybe it's server/location dependent?

Another post about this issue

Here is a pastebin with full curl logs of requests for both files

Here is another pastebin with just the timing information from ten requests on each file in a tight loop

Answer 1

I've been seeinig the same behavior.

GAE has some strange edge caching behavior for these javascript files. After the 4th or fifth consecutive request, the response time improves significantly (some type of edge caching of the gzipped content kicks in). In my experiments it's gone from around 1.2s -> 190ms

I've been able to reproduce this consistently across 3 GAE apps. If you use Chrome, you can go to the DevTools settings and disable cache (while DevTools is open). Reloading the page a few times will get your javascript transfer times down to the reasonable numbers.

Google's edge cache probably has some logic where it determines it won't bother caching gzipped js files until they're requested frequently enough. This would appear to encourage you to write a script that constantly downloads your js files to ensure that they download a few hundred milliseconds faster. I suspect that the edge cache is smart enough to only cache for one region at a time though.

Answer 2

Add mime_type: text to your JavaScript static resource.

Would need to look into what mime_type is being assumed, what what clever trick is being done for text vs other mime types...