Исходящая пропускная способность увеличилась в 4 раза по необъяснимой причине
Я запускаю игру, основанную на 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% запросов. Время ожидания не изменилось. Это выглядит действительно многообещающе:)
1 ответ
После отправки тикета (пришлось купить серебряный пакет поддержки), проблема была проанализирована Google, и это была действительно ошибка в движке приложения, которая вызывала расхождения между реальным использованием пропускной способности из журналов и расчетными значениями на панели мониторинга. Это решено сейчас.