我正在运行一个基于GWT + GAE的游戏，它包含许多静态图像文件（~25MB，大部分打包为JS GWT包）。我们目前每天约有450名活跃用户，每天约有30名注册用户。这个数字因为几周而非常稳定。最多，他们每天产生大约 10GB 的流量。 但上周发生了一件非常奇怪的事情：在本周中，11月19日，使用量增加到超过<40> ，从那以后它一直保持在这个水平。
我正在调查它几天，但到目前为止没有任何结果 - 所以我需要你的帮助和想法，因为结算支持忽略了我。
事实：
日期/ DAU / Bandwidht
15.11 / 385 / 6.5 GB
16.11 / 585/9 GB
17.11 / 660/10 GB
18.11 / 451/12 GB
19.11 / 455/46 GB
20.11 / 438/42 GB
21.11 / 429/44 GB
传出带宽大幅增加，但是当我们检查仪表板中的图表时，情况并不明显，为什么会发生这种情况（由于这里没有新的直接图片发布 - 抱歉）：
http://i.stack.imgur.com/HPfdV.jpg
19日，我们没有部署新版本或更改了应用程序的配置。
我们还检查了带宽相关组件（blob，mail，channel api） 但那天没有任何改变。
接下来，我从所有日期下载了日志并总结了所有响应大小，我得到了以下结果：
18.11：3.9 GB
19.11：4.2 GB
20.11：3.8 GB
21.11：4.1 GB
除了总尺寸和传出带宽之间的巨大差异之外，在日志中尺寸在19日之后也是相当稳定的。我现在不知道在哪里我应该寻找答案。哪些未记录的服务可能导致这种行为？
编辑28.11： 我在其他应用程序上部署了应用程序并进行了一些“单元”测试：
Clientside：Firebug测量〜20MB下载（一些图像和JS）
Serverside：在日志中，资源的每个GET的响应大小为0，状态为200（... 3.cache.js HTTP / 1.1“200 0 ...）和一个游戏会话的总大小日志是715kB。
App Engine仪表板：传出带宽0,11GB！
AppStats：none urlFetch，一对频道API发送消息 - 没什么了不起的。
尝试使用3个浏览器并累计输出0.33GB的带宽，虽然日志显示为2.5MB，并且根据客户端的总和结果大约为65MB（我的预期）。 缓存似乎有效，因为第二次加入，我只根据Firebug下载30kB，并且仪表板中的带宽计数器也不会在这种情况下上升。
非常感谢任何帮助和想法！
编辑10.12.2013： 正如我在答案中写的那样 - 现在修复了这个错误。另外，我还尝试了CloudFlare，所以我们昨天的带宽使用量为3,5GB（是的，1/12）！ 由于我们的应用程序是游戏，因此包含大量静态内容，因此cloudfalre为我们节省了75％的静态文件带宽和66％的请求。延迟没有改变。它看起来很有前途：）
答案 0 :(得分：1)
提交票证后（必须购买白银支持包），问题由谷歌分析，这确实是应用引擎中的一个错误，导致日志的实际带宽使用与仪表板中的计费值之间存在差异。 它现在已经解决了。
