java - DSE 图更多线程导致响应时间变慢

Question

我以前问过这个问题。但是再问一个具体的例子。

因此，我在我的 Mac 上本地运行了 DSE 图形。我有最简单的顶点创建，下面是遍历。

g.addV("company").property("id", companyId)
.property("name", "company_" + companyId)
.property(VertexProperty.Cardinality.list, "domainurls", "test.com", "anothertest.com")
.next();

现在我正在使用 Java TinkerPop3 API 进行调用。我有一个 DseSession 是这样得到的。

dseCluster = DseCluster.builder()
        .addContactPoints(contactPoints)
        .withGraphOptions(new GraphOptions().setGraphName("profilex_dev"))
        .build();
dseSession = dseCluster.connect();
DseGraph.traversal(dseSession)

我正在多线程应用程序中重新使用 GraphTraversalSource 的这个实例。我的观察，线程数量越多，响应时间越慢。

我使用 Java Microbenchmarking Harness 进行了测量，下面是我大致发现的结果

• 10 个线程 - 6 毫秒
• 50 个线程 - 34 毫秒
• 200 个线程 - 146 毫秒。

所以我的问题是 - 有没有一种方法可以优化它以使其运行得更快 - 任何需要设置的池选项等。在我的例子中，不仅仅是公司的创建和更多的图形突变/查询(大约 10 次这样的遍历)，随着线程数量的增加，整体响应时间变得次优。

请注意，上述响应时间也适用于简单的图形查询。因此，随着线程的增加，即使是简单的读取也会变慢。 (当然，当线程数量较少时非常好)。

Answer 1

不确定是否应该将其作为“答案”发布，但这样的格式比在评论中更容易。感谢提供完整的测试类，对调试和实验很有帮助。

一直在查看您的测试实现，实际上我注意到吞吐量随着并发级别的增加而下降。

我相信您所看到的是您的本地服务器节点最初未被使用以及服务器缓存很冷且不够活跃的副作用。您需要更大的预热阶段让您的本地节点能够足够快地开始响应，并了解在更高的并发性下单个请求时间如何不增加。

我运行了您的测试(只是单 session 测试)，当我的系统使用率较低时，当我开始您的测试时，结果看起来与您的完全相似。

但是，如果在 执行具有 10 - 20 - 50 个请求的测试之前放置一些额外的测试，如下所示:

    dseVertexQueryPerformance.testSingleSession(3000);
    dseVertexQueryPerformance.testSingleSession(6000);
    dseVertexQueryPerformance.testSingleSession(6000);
    dseVertexQueryPerformance.testSingleSession(6000);
    dseVertexQueryPerformance.testSingleSession(6000);
    dseVertexQueryPerformance.testSingleSession(9000);
    dseVertexQueryPerformance.testSingleSession(9000);
    dseVertexQueryPerformance.testSingleSession(9000);
    dseVertexQueryPerformance.testSingleSession(10);
    dseVertexQueryPerformance.testSingleSession(20);
    dseVertexQueryPerformance.testSingleSession(50);
    dseVertexQueryPerformance.testSingleSession(100);
    dseVertexQueryPerformance.testSingleSession(200);

我最终得到的结果如下:

End Test ::SingleSession, Average Time: 2.6, Total execution time: 5.891593 ms
For 10 threads, ::SingleSession took 2.6
End Test ::SingleSession, Average Time: 4.4, Total execution time: 7.830533 ms
For 20 threads, ::SingleSession took 4.4
End Test ::SingleSession, Average Time: 1.86, Total execution time: 20.378055 ms
For 50 threads, ::SingleSession took 1.86
End Test ::SingleSession, Average Time: 1.98, Total execution time: 47.487505 ms
For 100 threads, ::SingleSession took 1.98
End Test ::SingleSession, Average Time: 2.295, Total execution time: 92.793991 ms
For 200 threads, ::SingleSession took 2.295

我们可以有效地看出争用是由于 DSE Graph 或整个系统不够暖。

---

现在，回顾我上面提到的那些较长的运行，我观察到在使用连接的遍历源时发生了更多的争用或更多的工作。

我建议不要直接迭代遍历源，而是从遍历中创建一个 GraphStatement，如下所述:https://docs.datastax.com/en/developer/java-driver-dse/1.5/manual/tinkerpop/#data-stax-drivers-execution-compatibility

因此在您的测试中，我已将 getAVertex(GraphTraversalSource g) 更改为:

public class DSEVertexQueryPerformance {
    ...

    private GraphTraversalSource traversalSource = DseGraph.traversal();

    ....

    public long getAVertex(DseSession dseSession) {
        Instant begin = Instant.now();
        dseSession.executeGraph(DseGraph.statementFromTraversal(
            traversalSource.V(vertexId))
        );
        return Duration.between(begin, Instant.now()).toMillis();
    }

通过更改此方法，我能够使用当前的 g.V( ).next() 版本，使用 statementFromTraversal() 方法总执行时间约为 1400 毫秒。

最后，我还建议使用异步查询执行方法 (DseSession.executeGraphAsync())，因为它允许您并行处理所有请求，而无需在客户端使用线程池，最终减轻客户端应用程序的压力。