解析服务器 - 保存具有许多字段的对象 - 架构验证时间过长(enforceFieldExists)
Parse Server - Saving objects with many fields - Schema Validation takes too long (enforceFieldExists)
我们正在使用 ParseServer 将基于 CloudCode 的应用程序迁移到 Heroku。
使用版本:
- 解析@1.8.5
- 解析服务器@2.2.16
我们注意到(很难不注意到)保存一些文件的速度非常慢。这些对象通常一次保存几个 - 2 到 6 个对象(使用 Parse.Object.saveAll
触发对 /1/batch
的 REST 调用
保存这些对象中的每一个现在需要 4 到 12 秒之间的任何时间。深入研究 Parse 代码,很容易看出模式验证是原因。
SchemaController.validateObject() {
...
SchemaController.enforceFieldExists()
我们使用触发器进行简单验证,但根据 RestWrite.js
中的逻辑,这会导致架构验证执行两次 - 一次在触发器之前,一次在触发器之后。
问题在于我们的集合有大约40个字段。 SchemaController.enforceFieldExists()
在尝试验证 每个字段 时加载整个模式两次。此外,它总是尝试写入模式文档(同样,每个字段),通常只会失败,因为所有字段都已在模式中列出。
这意味着我们为每个对象获得大约 240 次数据库往返的开销,并且我们通常在每次调用中存储最多 5 个对象。加起来超过 1000 次数据库往返。所以我们很容易超过 30 秒的 Heroku 路由器超时限制。
我的问题是:
- 我可以做些什么来加快验证速度吗? (没有找到相关的文档或设置)
- 是否计划或在任何地方提供针对此冗余实施的修复?
- 假设我们不经常添加字段,我可以安全地阉割
enforceFieldExists()
不做任何其他事情吗?此集合 (_SCHEMA
) 用于其他 tan 在 Dashboard UI 中绘制表格的是什么?
- 我目前正在考虑修补此功能,使其对 npm 安装后脚本不执行任何操作。这听起来是个好方法吗?
感谢对此的任何帮助,
罗恩
此拉取请求正在解决此问题 https://github.com/ParsePlatform/parse-server/pull/2286
如果当前字段可用,这将跳过尝试写入架构。
这应该会很快发布
我们正在使用 ParseServer 将基于 CloudCode 的应用程序迁移到 Heroku。 使用版本:
- 解析@1.8.5
- 解析服务器@2.2.16
我们注意到(很难不注意到)保存一些文件的速度非常慢。这些对象通常一次保存几个 - 2 到 6 个对象(使用 Parse.Object.saveAll
触发对 /1/batch
保存这些对象中的每一个现在需要 4 到 12 秒之间的任何时间。深入研究 Parse 代码,很容易看出模式验证是原因。
SchemaController.validateObject() {
...
SchemaController.enforceFieldExists()
我们使用触发器进行简单验证,但根据 RestWrite.js
中的逻辑,这会导致架构验证执行两次 - 一次在触发器之前,一次在触发器之后。
问题在于我们的集合有大约40个字段。 SchemaController.enforceFieldExists()
在尝试验证 每个字段 时加载整个模式两次。此外,它总是尝试写入模式文档(同样,每个字段),通常只会失败,因为所有字段都已在模式中列出。
这意味着我们为每个对象获得大约 240 次数据库往返的开销,并且我们通常在每次调用中存储最多 5 个对象。加起来超过 1000 次数据库往返。所以我们很容易超过 30 秒的 Heroku 路由器超时限制。
我的问题是:
- 我可以做些什么来加快验证速度吗? (没有找到相关的文档或设置)
- 是否计划或在任何地方提供针对此冗余实施的修复?
- 假设我们不经常添加字段,我可以安全地阉割
enforceFieldExists()
不做任何其他事情吗?此集合 (_SCHEMA
) 用于其他 tan 在 Dashboard UI 中绘制表格的是什么? - 我目前正在考虑修补此功能,使其对 npm 安装后脚本不执行任何操作。这听起来是个好方法吗?
感谢对此的任何帮助, 罗恩
此拉取请求正在解决此问题 https://github.com/ParsePlatform/parse-server/pull/2286
如果当前字段可用,这将跳过尝试写入架构。
这应该会很快发布