我有一个非常简单的应用程序引擎应用程序，可以提供存储在blobstore中的1.8Kb - 3.6Kb gzip压缩文件。从数字文件ID到blobkey的映射存储在数据存储区中，并缓存在memcache中。 servlet实现是微不足道的：在请求中接收数字文件ID;从memcache / datastore中检索blobkey，并调用标准BlobstoreService.serve(blobKey, resp)来提供响应。正如预期的那样，应用程序日志显示响应大小始终与提供的blobstore文件大小相匹配。
我一直在进行一些专注的卷测试，这表明一直报告的出局带宽配额利用率大约是我收到请求时的2倍。我一直在运行100k个请求，一次总结在客户端收到的字节，将其与应用程序日志进行比较，除了传出带宽配额利用率之外的所有余额。
了解如何确定上述简单应用程序的传出带宽配额利用率的任何帮助？我错过了什么或者没有考虑到什么？为什么它与app日志中响应大小显示的总数不符？
[更新2013.03.04：我放弃使用blobstore并恢复为直接将blob存储在数据存储区中。传出带宽利用率现在与预期完全一致。似乎2x乘数与某种方式与blobstore的使用有关（但它仍然无法解释）。我在使用blobstore服务时遇到了其他几个问题;最有问题的是额外的数据存储区读取和写入（与数据存储区中管理的blobinfo和blobindex元数据相关 - 这是我最初试图通过将数据迁移到blobstore来减少的）。对我来说一个特别严重的问题是：https://code.google.com/p/googleappengine/issues/detail?id=6849。我认为这是一个blobstore服务内存泄漏;创建blob后，您永远无法删除数据存储区中的blob元数据。我将永远为此付出代价，因为我愚蠢到可以进行24小时的音量和性能测试，现在无法释放测试期间使用的存储空间。看来blobstore目前仅适用于非常特定的场景（即永久静态数据）。经常刷新或更改的具有大量流失或数据的对象不应存储在blobstore中。]
答案 0 :(得分：0)
可以删除blobstore数据（我不推荐它，因为它可能会导致意外行为），但前提是您知道它在__BlobInfo__中保存的表格__BlobFileIndex__。这样做了，因此您上传的文件名称不同，并且意外地替换了旧文件。
有关存储在数据存储区中的表的完整列表，您可以运行SELECT * FROM __kind__。
我不确定为什么您的应用引擎应用消耗了2倍的传出带宽，但我会自己测试。
另一种方法是使用Google云端存储。如果您使用default bucket for your app engine app, you get 5GB free storage
经常刷新或更改的具有大量流失或数据的对象不应存储在blobstore中。
确实如此，您可以使用云存储或数据存储（云存储是存储服务的不可变对象）。 Blobstore更适合通过<input type='file' />表单上传文件。 （从最近开始，从应用程序内部编写文件已被弃用，有利于云存储）