График DSE: большее количество потоков приводит к увеличению времени отклика

Не уверен, что это должно быть опубликовано как «ответ», но форматирование проще, чем в комментарии. Спасибо за предоставление полного тестового класса, было полезно отладить и поэкспериментировать.

Просматривая вашу тестовую реализацию, я действительно смог заметить снижение пропускной способности по мере увеличения уровня параллелизма.

Я считаю, что то, что вы видите, является побочным эффектом того, что ваш локальный узел сервера изначально не использовался, а кэши сервера были холодными и недостаточно активными. Вам нужны большие фазы прогрева, чтобы ваш локальный узел мог начать отвечать достаточно быстро и увидеть, как при более высоком уровне параллелизма время отдельных запросов не увеличивается.

Я провел ваши тесты (только односессионные), когда моя система мало загружена, и когда я запускаю ваши тесты, результаты выглядят точно так же, как ваши.

Однако, если поставить дополнительные тесты перед выполнением тестов с 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();
    }

Изменив этот метод, я смог перейти с общего времени выполнения ~1900 мс, скажем, для 9000 запросов (dseVertexQueryPerformance.testSingleSession(9000);) с вашей текущей версией g.V().next(), до общего времени выполнения ~1400 мс с использованием метода statementFromTraversal().

Наконец, я также рекомендую использовать асинхронные методы выполнения запросов (DseSession.executeGraphAsync()), так как это позволит вам распараллелить все ваши запросы без необходимости использования пулов потоков на стороне клиента, что в конечном итоге снизит нагрузку на клиентское приложение.