Исходящая полоса пропускания увеличилась в 4 раза по какой-то необъяснимой причине

Я запускаю игру, основанную на GWT+GAE, которая содержит много статических файлов изображений (~25 МБ, в основном упакованных в пакет JS GWT). В настоящее время у нас около 450 активных пользователей ежедневно и около 30 регистраций в день. Эти цифры довольно постоянны уже пару недель. В max они генерировали около 10Gb трафика в день.
Но на прошлой неделе произошло нечто очень странное: в середине недели, 19 ноября, использование увеличилось до более 40GB, и с тех пор он оставался на этом уровень.

Я изучаю его уже пару дней, но пока без каких - либо результатов-так что мне нужна ваша помощь и идеи, так как Служба поддержки счетов игнорирует меня.

Факты:

Date / 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 ГБ

19.11: 4.2 Гб

20.11: 3,8 ГБ

21.11: 4.1 ГБ

Помимо огромного расхождения между общими размерами и исходящей полосой, в журналах размеры довольно постоянны и после 19-го. В данный момент я понятия не имею, где еще искать ответ. Какие службы, которые не регистрируются, могут привести к такому поведению?

Правка 28.11:
Я развернул тогда приложение на другом app-id и сделало некоторое "модульное" тестирование:

Клиентская сторона: Firebug измеряется ~20 МБ загрузки (некоторые изображения и JS)

Serverside: в журналах размер ответа каждого GET ресурса равен 0 со статусом 200 (...3.кэш.js HTTP / 1.1 " 200 0 ...) а общий размер одной игровой сессии по логам составляет 715кб.

Панель мониторинга App Engine: исходящая пропускная способность 0,11 ГБ!

AppStats: none urlFetch, пара каналов API send message-ничего впечатляющий.

Попробовал его с 3 браузерами и накопил 0,33 ГБ исходящей полосы пропускания, хотя логи говорят 2,5 МБ и согласно суммированному результату клиентов около 65 МБ (чего я и ожидал).
Кэширование, похоже, работает, так как я подключился во второй раз, я загружаю только 30kB в соответствии с Firebug, а также счетчик пропускной способности в приборной панели не поднимается в этой ситуации.

Любая помощь и идеи очень ценятся!

Правка 10.12.2013:
Как я уже писал в ответе-баг есть теперь исправлено. Кроме того, я дал также CloudFlare попробовать, и поэтому у нас было вчера использование полосы пропускания 3,5 ГБ (да, 1/12)!
Поскольку наше приложение является игрой и поэтому состоит из большого количества статического контента, cloudfalre экономит нам 75% пропускной способности статических файлов и 66% запросов. Задержка не изменилась. Это выглядит действительно многообещающе:)