我在地图中为数据存储区中的每个用户保留邮件。它被保存为由唯一名称键入的未编制索引的序列化值。用户可以一次向多个用户发送消息。目前我为（例如）20个目标执行批量获取，更新每个目标中的序列化值，然后执行批量放置。序列化的消息大小足够小，不重要，大约1KB。
这对用户来说很快，appstats中显示的实时时间是90ms。但是，cpu-time成本是918ms。这会导致警告，如果我希望向50个用户发送消息，可能会因使用率过高而变得昂贵，或者会造成麻烦。有没有办法减少这个cpu时间成本，无论是数据存储调整，还是我错过的架构的明显变化？任务队列解决方案将删除警告，但实际上只会重新分配成本。
编辑：数据存储区键是接收方的用户名，值是存储为序列化映射的消息，其中key是发送方的用户名，Message是保存两个整数的简单对象。有两种类型的请求。上面描述的“更新”类型，其中检索消息映射，将新消息添加到地图，并存储地图。 “获取”类型是读取消息的收件箱所有者，这是基于密钥的简单获取。我的想法是，即使这被分成多值关系或类似关系，这也提高了保真度（允许一次更新两次），但是只要它是一个简单的键值方法，put工作量仍然是相同的
答案 0 :(得分：1)
听起来你已经在相当有效地做事了。你不太可能能够大幅降低这一点。无论如何，每个请求少于1000 cpu毫秒是一个相当合理的数量。
通过拆分实体可能会获得两件事：如果您的列表很长，那么当您只需要阅读或修改其中的一小部分时，就可以节省读取和编写大型实体的CPU成本，并且''重新节省事务冲突。也就是说，如果多个任务需要同时向队列添加项目，则可以在不重试事务的情况下执行此操作，从而节省CPU时间。