Google App Engine：任务队列上的bucket_size参数
关于 Bucket_size 参数的 Google 文档仅提供了简要说明定义、维基百科链接和示例：
bucket_size
限制队列处理的突发性，
即更大的桶尺寸允许更大的尖峰 队列的执行率。为了 例如，考虑一个具有速率的队列 为 5/s，桶大小为 10。如果 该队列对于某些人来说已处于非活动状态 时间（允许其“令牌桶” 填满），突然有20个任务 排队，将被允许 立即执行10个任务。但在 接下来的第二个，只剩下5个了 任务将能够被执行 因为令牌桶已经 已耗尽并正在补充 指定速率为 5/s。
您能否解释一下 Bucket_size 参数以及该参数的用途？
Google documentation on Bucket_size parameter gives just a brief definition, a Wikipedia link and an example:
bucket_size
Limits the burstiness of the queue's processing,
i.e. a higher bucket size allows bigger spikes in
the queue's execution rate. For
example, consider a queue with a rate
of 5/s and a bucket size of 10. If
that queue has been inactive for some
time (allowing its "token bucket" to
fill up), and 20 tasks are suddenly
enqueued, it will be allowed to
execute 10 tasks immediately. But in
the following second, only 5 more
tasks will be able to be executed
because the token bucket has been
depleted and is refilling at the
specified rate of 5/s.
Could you please provide an explanation of Bucket_size parameter and in which way this parameter could be useful?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最简单的描述方式是它定义了允许队列服务的需求峰值有多高。
例如，如果您定义一个每秒 5 个请求的队列，桶内有 10 个请求。这意味着它将主要以每秒 5 个请求的速率执行，但当达到每秒 10 个请求时，峰值将达到每秒 10 个。
The simplest way to describe is that it defines how high a peak in demand you allow a queue to serve.
For example if you define a queue for 5/s requests, with a bucket of 10. This means that it will mostly perform at the rate of five requests per second, but when it's got to it will peak to ten per second.
您发布的解释相当全面。
任务队列仅当桶中有足够的令牌时才会执行任务，并以您指定的速率重新填充桶。
例如，您可能希望使用较低的bucket_size来避免达到每分钟电子邮件配额，或者避免同时运行太多需要使用相同实体组来减少争用的任务。
如果不知道您想对自己的任务做什么，就很难就如何设置此参数提出建议；对于大多数用途来说，默认值可能就很好了。
The explanation you posted is fairly comprehensive.
The task queue will only execute tasks when there are enough tokens in the bucket, and will refill the bucket at your specified rate.
You might want to use a lower bucket_size to avoid, for example, hitting the per-minute email quotas, or to avoid having too many tasks running at the same time that need to use the same entity groups to cut down on contention.
Without knowing what you want to do with your own tasks, it's difficult to make suggestions on how you might want to set this parameter; for most uses the default might be perfectly fine.