【问题标题】:ExpressJS app which receives around 70 requests per second - slow Cassandra performanceExpressJS 应用程序每秒接收大约 70 个请求 - Cassandra 性能缓慢
【发布时间】:2019-06-02 02:30:55
【问题描述】:

这不是与代码有关的问题,而是与服务器性能和我应该检查的事情有关的问题。所以我有一个 ExpressJS 服务器,它连接到一个 cassandra db(1 个种子节点和 1 个集群上的 2 个节点,所以总共 3 个节点)。 API 与 cassandra db 种子节点在同一台服务器上运行。我在本地网络中总共有 3 台服务器。

所以结构看起来像这样 -

服务器 1 运行 API 和种子 cassandra 节点。 服务器 2 运行 cassandra 节点。 服务器 3 运行 cassandra 节点。

每台服务器都有 8GM 内存和 2.5Ghz CPU。

默认情况下,每秒大约有 70 个请求,它们执行以下操作 -

1) 调用从 cassandra 的表中读取数据的函数(使用物化视图)。 2) 从 cassandra db 读取另一个表(使用物化视图)。 3) 将数据发布到 cassandra 中的第三张表。

调用的第二个函数非常相似,它使用物化视图进行 1 次读取和 1 次发布。

每秒调用的函数之间的比例差异约为函数 1 被调用 30 次(执行 2 次读取和 1 次发布),以及大约 40 次函数 2 被调用(执行 1 次读取和 1 次发布)。

一切都会很好,但是请求的延迟会时不时地跳跃,有时大约需要 10 毫秒,但每 5 到 10 秒就会上升到 3 到 30 秒。 cassandra 似乎也不稳定 - 在有 3-30 秒的请求时间期间,cassandra 似乎在某些请求上超时。

我应该首先检查什么?我需要额外的节点吗?如何确定是否有足够的节点来处理发送到 cassandra db 的数据量?我是否应该将 API 与 cassandra 节点分开 - 从而将 API 服务器放在单独的服务器上,例如服务器 4?

【问题讨论】:

标签: express cassandra express-cassandra


【解决方案1】:

物化视图非常适合读取操作,但会带来写入的开销;您需要考虑执行其魔法所需的一些开销:

  • 物化视图将需要额外的资源来跟踪其来源的更新;当您与多个物化视图交互时,这种情况会变得更糟,就像您建议的第一个场景一样。
  • 如果帖子的数据写在物化视图的同一源中,这将取决于表中使用的主键的复杂性,如here 所述。

我将探索的第一个选项是非规范化并为第一个函数创建一个单独的表,因此您将执行一次读取,而不是两次。

我的回答中有很多猜测,因为结构和表模式有很多未知数;如果您启用跟踪,您可能会获得更好的洞察力,在我们的案例中,正如TLP 所解释的那样,我们使用 openzipkin 获得了良好的结果@

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-04-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-04-28
    相关资源
    最近更新 更多