时间戳

首页 > 解决方案 > ExpressJS 应用程序每秒接收大约 70 个请求 - Cassandra 性能缓慢

express - ExpressJS 应用程序每秒接收大约 70 个请求 - Cassandra 性能缓慢

问题描述

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

所以结构看起来像这样 -

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

每台服务器都有 8GM 的 ram 和 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？

标签： expresscassandraexpress-cassandra

解决方案

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

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

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

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

推荐阅读