这不是一个与代码相关的问题,而是与服务器性能和我应该检查的内容相关的问题。所以我有一个expressjs服务器,它连接到一个cassandra数据库(1个种子节点和1个集群上的2个节点,总共3个节点)。该api与cassandra db种子节点运行在同一台服务器上。我在本地网络中总共有3台服务器。
所以结构看起来像这样-
服务器1运行api和种子cassandra节点。服务器2运行cassandra节点。服务器3运行cassandra节点。
每台服务器有8gm的ram和2.5ghz的cpu。
默认情况下,每秒钟大约有70个请求,它们执行以下操作-
1) 调用一个函数,该函数从cassandra表中读取数据(使用物化视图)。2) 从cassandradb读取另一个表(使用物化视图)。3) 将数据发布到cassandra中的第三个表。
调用的第二个函数非常类似,它使用物化视图和post进行读取。
每秒调用的函数之间的比例差大约是调用函数1的30倍(2读1后),和调用函数2的40倍(1读1后)。
一切都会很好,但请求的延迟会时不时地跳跃,有时需要10毫秒左右,但每5-10秒就会上升到3-30秒。另外,cassandra似乎不稳定—在有3-30秒请求时间的期间,cassandra似乎在某些请求上超时。
我要检查的第一件事是什么?我是否需要额外的节点,以及如何确定是否有足够的节点来处理发送到cassandradb的数据量?我是否应该将api与cassandra节点分开—从而将api服务器放在单独的服务器上,例如服务器4?
1条答案
按热度按时间ecbunoof1#
物化视图对于读操作来说是很好的,但是它们会以写操作为代价;您需要考虑执行其魔术所需的一些开销:
物化视图将需要额外的资源来跟踪其源的更新;当您与多个物化视图交互时,情况会变得更糟,如您提出的第一个场景中所示。
如果post的数据写在物化视图的同一个源中,这将取决于表中使用的主键的复杂性,如这里所述。
我要探讨的第一个选项是反规范化并为第一个函数创建一个单独的表,因此您将执行一次读取,而不是两次读取。
在我的回答中有很多猜测,因为在结构和表模式上有很多未知的东西;如果您启用跟踪,您可能会得到更好的了解,在我们的案例中,我们使用openzipkin获得了很好的结果,正如tlp所解释的那样