【问题标题】:Does cursor.observe slow down server performance?cursor.observe 会降低服务器性能吗?
【发布时间】:2013-02-02 09:19:02
【问题描述】:

我已经找到了

_suppress_initial: true

但它不适用于 0.54

我想观察一些集合,比如 Orders Collection。

如果我有大量订单并且添加新订单时我想使用观察来更新另一个集合。

我没有将观察放入 Meteor.publish 如果我不停止观察会怎样,如果我在服务器运行期间一直观察它会减慢服务器吗?

if Meteor.isServer

    obOrders = Orders.find({}).observe # when server restart does this slow down performance ?

        _suppress_initial: true # doesnt work

        added: (order) ->

            console.log order # still add exist documents

            if Date.now() - order.timestamp < 500
                console.log order # update another one

或者我应该限制 Orders.find {},限制:50 并按时间戳排序以观察最新文档?

在服务器 Meteor.startup 或 Meteor.publish 上进行观察,这两个条件有什么不同?

如果我把它放到 Meteor.startup 中,这是否意味着我会进行单例观察?

【问题讨论】:

  • 同样的事情,也无法让 _suppress_initial 为我工作

标签: meteor


【解决方案1】:

现在,observe 必须将整个查询结果永久保存在内存中。因此,如果您调用Orders.observe({}),那么只要观察运行,服务器就会将订单集合的完整副本保存在内存中。这是因为,在幕后,observe 在检测到潜在变化时将旧查询结果与新查询结果进行比较。这是为了确保来自 observe 的结果始终 100% 正确,即使由于多个进程同时写入数据库而存在竞争条件。

因此,如果您查询有限数量的文档,例如最近的五个订单,或最近 5 分钟内下的订单,它将显着减少 RAM 使用量(可能还有 CPU 使用量)。但如果您这样做您必须小心确保不会遗漏任何文件。例如,如果您正在观察最近 5 分钟内插入的文档,但您的服务器关闭了 10 分钟,那么您可能不会收到某些订单的添加消息。或者,如果您正在观察最近的 5 个文档,然后另一个节点一次插入 1000 个文档,您可能只会收到最近 5 条消息的添加消息(因为observe 不保证您会观察每个中间状态,只是您的添加/删除/更改消息最终会让您了解当前状态。)

至于你将在哪里开始这样的观察:如果你从服务器上的 Meteor.startup 执行它,它会一直运行,但只会运行它的一个副本(现在 - 将来 Meteor将启动多个服务器进程,您将需要更新您的代码。)如果您从发布处理程序执行此操作,那么它将仅在至少有一个订阅时运行(并且仅消耗资源)。最近的 Meteor 版本将删除在完全相同的查询上调用的 observes,因此如果您有 1000 个对调用 Orders.find({}).observe({ ... }) 的发布处理程序的订阅,它不应该比只有一个资源消耗更多的资源。 (记得在客户端退订时停止每个观察。)

根据您的操作,在创建每个订单时安排任务可能比使用added 更容易。例如,您可以有一个方法 createOrder 插入订单,并将项目添加到 ordersToProcess 集合,然后分别有代码从 ordersToProcess 集合中拉出项目并一次处理一个,然后然后删除它们。或者,如果不需要太长时间,您可以直接从 createOrder 方法进行处理。

【讨论】:

猜你喜欢
  • 1970-01-01
  • 2018-12-12
  • 1970-01-01
  • 1970-01-01
  • 2011-04-26
  • 1970-01-01
  • 1970-01-01
  • 2015-10-29
  • 1970-01-01
相关资源
最近更新 更多