Исходящая пропускная способность в 2 раза превышает общую пропускную способность

Question

У меня есть очень простое приложение, которое обслуживает сжатые файлы размером 1,8 КБ - 3,6 КБ, хранящиеся в blobstore. Карта из числового идентификатора файла в blobkey хранится в хранилище данных и кэшируется в memcache. Реализация сервлета тривиальна: числовой идентификатор файла получен в запросе; Blobkey извлекается из memcache/datastore и стандартного BlobstoreService.serve(blobKey, resp) вызывается для обслуживания ответа. Как и ожидалось, журналы приложений показывают, что размеры ответов всегда соответствуют размеру обслуживаемого файла хранилища.

Я проводил целенаправленное тестирование томов, и это показало, что использование квоты на исходящую полосу пропускания, как сообщается, примерно в 2 раза больше, чем я ожидаю, учитывая полученные запросы. Я выполнял прогоны по 100 тыс. Запросов за один раз, суммируя байты, полученные на клиенте, сравнивая это с журналами приложений и всеми балансами, за исключением использования квот исходящей полосы пропускания.

Любая помощь в понимании, как определяется использование квоты исходящей полосы пропускания для простого приложения, которое я описал выше? Чего мне не хватает или не приходится учитывать? Почему бы не соответствовать итоговым значениям, указанным для размеров ответов в журналах приложений?

[Обновление 2013.03.04: я отказался от использования хранилища больших двоичных объектов и вернулся к хранению больших двоичных объектов непосредственно в хранилище данных. Использование исходящей полосы пропускания теперь соответствует ожиданиям. Похоже, что множитель 2x так или иначе связан с использованием магазина блогов (но он остается необъяснимым). Я столкнулся с несколькими другими проблемами при использовании сервиса blobstore; наиболее проблематичными были дополнительные операции чтения и записи в хранилище данных (которые связаны с метаданными blobinfo и blobindex, управляемыми в хранилище данных - и это то, что я изначально пытался уменьшить, перенеся мои данные в хранилище BLOB-объектов). Особенно серьезная проблема для меня заключалась в следующем: https://code.google.com/p/googleappengine/issues/detail?id=6849. Я считаю это утечкой памяти в сервисе интернет-магазина; после создания большого двоичного объекта вы никогда не сможете удалить метаданные большого двоичного объекта в хранилище данных. Я буду платить за это вечно, так как я был достаточно глуп, чтобы провести 24-часовой тест объема и производительности, и теперь я не могу освободить хранилище, используемое во время теста. Похоже, что в настоящее время хранилище блогов подходит только для использования в очень специфических сценариях (т. Е. Постоянно статических данных). Объекты с большим количеством оттока или данных, которые часто обновляются или изменяются, не должны храниться в блоб-магазине.]

Answer 1

Данные из хранилища можно удалить (я не рекомендую, поскольку это может привести к непредвиденному поведению), но только если вы знаете таблицу, в которой они сохранены __BlobInfo__ а также __BlobFileIndex__, Это сделано, чтобы ваши загруженные файлы не имели одинакового имени и случайно заменили старый файл.

Для получения полного списка таблиц, которые хранятся в хранилище данных, вы можете запустить SELECT * FROM __kind__,

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

Альтернативой является использование Google Cloud Storage. Если вы используете корзину по умолчанию для своего приложения, вы получаете 5 ГБ свободного места

Объекты с большим количеством оттока или данных, которые часто обновляются или изменяются, не должны храниться в BLOB-магазине.

Это правда, вы можете использовать либо облачное хранилище, либо хранилище данных (облачное хранилище - это служба хранения неизменяемых объектов). Blobstore был больше для загрузки файлов через <input type='file' /> формы. (с недавних пор запись файлов изнутри приложения устарела в пользу облачного хранилища)