让我逐个帮你拆解这两个关于NDB fetch操作的问题：

问题1：Fetch操作的非RPC时间内，系统在执行什么？ #

当你调用NDB的fetch()方法时，除了等待Datastore RPC响应的时间，应用实例这边的非RPC时间主要消耗在这些核心操作上：

• 实体反序列化：Datastore返回的是二进制格式的Protocol Buffer数据，系统需要把这些原始数据转换成你定义的Object模型实例——包括映射字段类型、处理嵌套实体/结构化属性（比如日期、Blob、GeoPt这类特殊类型）、初始化对象的各个属性。
• 结果集的内存管理：创建并维护存储所有实体实例的列表，处理内存分配、对象引用计数，以及Python解释器层面的内存清理预备操作（比如GC的后台扫描）。
• 查询结果的内部处理：即使是全表查询，NDB也会处理分页逻辑（默认分批拉取数据），合并多批次的RPC结果，维护结果集的完整性；如果查询带有客户端侧的过滤逻辑（虽然大部分过滤在服务端完成），也会在这里执行。
• NDB上下文的维护：跟踪当前请求中的实体状态、处理事务相关的钩子（如果存在），以及为App Stats这类工具收集性能监控数据。

问题2：2000个实体fetch时，18秒非RPC时间的具体操作 #

你已经关闭了本地缓存和Memcache，所以这18秒的非RPC时间几乎全部集中在以下几个高耗时环节：

• 大规模实体反序列化：2000个实体的Protocol Buffer数据转成Object实例的过程是最大的耗时点。如果你的Object模型有大量属性、嵌套结构，或者包含Blob/大文本这类需要额外处理的字段，每个实体的反序列化都会消耗更多CPU，2000个的累加效应直接拉满了非RPC时间。
• 大结果列表的内存构建：创建一个包含2000个实体的列表需要大量连续内存分配，同时Python的垃圾回收机制会在内存占用上升时触发扫描和清理操作，这部分也会占用不少CPU时间。
• 分批拉取的结果合并：NDB的fetch()默认会分批从Datastore拉取数据（通常每批次最多1000个实体），即使你没显式使用游标，内部也会自动处理多次RPC的结果合并、去重（如果有），这部分逻辑的执行也会消耗非RPC时间。
• 自定义钩子的执行：如果你的Object模型定义了_post_get_hook这类自定义钩子函数，每个实体加载后都会执行一次这个钩子——2000次的重复执行会大幅增加总耗时，这是很容易被忽略的点，建议检查你的模型定义。

另外，App Stats的性能监控代码会在操作的各个阶段注入打点逻辑，这也会带来一点点额外的开销，但相对于前面的环节占比很小。

内容的提问来源于stack exchange，提问作者hassassin