Meteor.logout()和Meteor.call()太慢了

时间:2017-06-01 13:28:54

标签: meteor

我有一个网络应用程序。我生活在Meteor.logout()和Meteor.call()的时间问题。当我meteor.logout()时,它需要大约30-40秒之间的时间。 Meteor.call()也是如此。大约200-250个客户同时使用该系统。

如果客户在应用程序屏幕上看到大约100-200个项目,则此延迟时间非常多。但10-20项,它有点好。我们每5-10秒获得一次数据,这些数据在这些项目上彼此不同。我的意思是,直播屏幕。

当我使用相同的代码和相同的数据库在不同的端口上使用此系统时,我不会遇到此问题。

我无法理解。可能是什么原因呢。我需要你的想法和帮助。

4 个答案:

答案 0 :(得分:1)

注销功能等待服务器的回调,配置服务器的方式有问题。

在另一台机器上运行相同的代码,不应该发生。

答案 1 :(得分:1)

您可以在每个方法和出版物中使用this.unblock()。 默认情况下,Meteor进程逐个请求,如果正在处理,它将对所有请求进行排队。

这可能是由于某些较大功能的某些功能需要更多时间而服务器的所有其他请求必须等到它结束。

您只需将this.unblock()放在每个方法和出版物的开头,它就不会阻止您的请求。 感谢

答案 2 :(得分:1)

我解决了我的问题。

虽然从一侧执行集合更新过程,但是从另一侧执行流星发布过程。随着客户端数量的增加,服务器无响应。我用Mongodb oplog功能解决了这个问题。

感谢您的关注。

答案 3 :(得分:0)

可能有多种原因。 可以取消订阅集合,这意味着客户端和服务器交换正在取消订阅的id列表。

许多人都有反应式用户界面,这些用户界面突然被传输的数据量所淹没,需要自行更新。 (示例角度摘要循环始终在meteor sub / unsub之后运行)

Chrome Inspector - 网络websocket框架是了解Meteor注销多久以及在服务器返回注销请求结果之前来回传递消息的最佳工具。

您也可以在订阅中使用this.unblock()功能。这样,您的子写入并行运行并且不会相互阻塞