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

Question

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

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

Факты:

Дата / DAU / Bandwidht

15,11 / 385/ 6,5 ГБ

16,11 / 585 / 9 ГБ

17.11 / 660 / 10 ГБ

18,11 / 451 / 12 ГБ

19,11 / 455 / 46 ГБ

20,11 / 438 / 42 ГБ

21,11 / 429 / 44 ГБ

Наблюдается значительное увеличение исходящей полосы пропускания, но когда мы изучаем диаграммы с панели инструментов, неясно, почему это происходит (из-за того, что здесь новинка, прямая публикация изображения невозможна - извините):

19-го мы не развернули новую версию и не изменили конфигурацию приложения.

Мы также рассмотрели компоненты, связанные с пропускной способностью (blob, mail, channel api), но в этот день ничего не изменилось.

Далее я загрузил журналы за все дни и суммировал все размеры ответов, и получил следующий результат:

18.11: 3.9 ГБ

19,11: 4,2 ГБ

20,11: 3,8 ГБ

21,11: 4,1 ГБ

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

РЕДАКТИРОВАТЬ 28.11: Я развернул приложение на другой идентификатор приложения и провел некоторое "модульное" тестирование:

Clientside: загрузка Firebug ~20MB (некоторые изображения и JS)

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

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

AppStats: нет urlFetch, пара канальных API отправляют сообщения - ничего особенного.

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

Любая помощь и идеи с благодарностью!

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

Answer 1

После отправки тикета (пришлось купить серебряный пакет поддержки), проблема была проанализирована Google, и это была действительно ошибка в движке приложения, которая вызывала расхождения между реальным использованием пропускной способности из журналов и расчетными значениями на панели мониторинга. Это решено сейчас.