cassandra java驱动程序-高延迟，同时用多线程提取数据

Question

我可以在datastax cassandra driver（3.0）中看到一个奇怪的行为。我创建了一个新集群，然后使用同一个集群对象启动了一组线程。如果我将线程数保持在1或2，我会看到平均提取时间为5ms，但如果我将线程数增加到60，提取时间将增加到200ms（每个线程）。奇怪的是，如果我让60个线程的应用程序运行，并在同一台机器上启动另一个只有1个线程的进程，那么单线程应用程序的提取时间又是5毫秒。所以这似乎与客户有关。我多次重复相同的测试，以避免缓存冷启动问题。以下是群集对象的配置方式：

    PoolingOptions poolingOptions = new PoolingOptions();
    poolingOptions
        .setConnectionsPerHost(HostDistance.LOCAL,  parallelism, parallelism+20)
        .setConnectionsPerHost(HostDistance.REMOTE, parallelism, parallelism+20)
        .setMaxRequestsPerConnection(HostDistance.LOCAL, 32768)
        .setMaxRequestsPerConnection(HostDistance.REMOTE, 2000);

    this.cluster = Cluster.builder()
            .addContactPoints(nodes)
            .withRetryPolicy(DowngradingConsistencyRetryPolicy.INSTANCE)
            .withReconnectionPolicy(new ConstantReconnectionPolicy(100L))
            .withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
            .withCompression(Compression.LZ4)
            .withPoolingOptions(poolingOptions)
            .withProtocolVersion(ProtocolVersion.V4)
            .build();

有没有人经历过同样的问题？这似乎是一个客户端配置问题。也许Netty还缺少一些配置？

更新1应用程序正在使用以下查询提取数据块：

select * from table where id=? and ts>=? and ts<?

所以我有60个线程并行地提取这些数据。id是分区键。每个查询都由线程执行，如下所示：

//Prepare statement
PreparedStatement stmt = ... get the prepared statment cached
BoundStatement bstmt = stmt.bind(...)
//Execute query
long te1 = System.nanoTime();       
ResultSet rs = this.session.execute(bstmt);
long te2 = System.nanoTime();
//Fetch...
Iterator<Row> iterator = rs.iterator();
while (!rs.isExhausted() && iterator.hasNext()) { .... }

会话是一个跨所有线程共享的会话。我所测量的是会议的平均时间。execute（）方法调用。

谢谢

更新2：这里是模式定义

CREATE TABLE d_t (
    id bigint,
    xid bigint,
    ts timestamp,
    avg double,
    ce double,
    cg double,
    p double,
    w double,
    c double,
    sum double,
    last double,
    max double,
    min double,
    p75 double,
    p90 double,
    p95 double,
    squad double,
    sumq double,
    wavg double,
    weight double,
    PRIMARY KEY ((id), xid, ts)
) WITH CLUSTERING ORDER BY (xid DESC, ts DESC)
and  compaction = {'class': 'SizeTieredCompactionStrategy'} 
and gc_grace_seconds=86400
and caching = { 'keys' : 'ALL', 'rows_per_partition':'36000' }
and min_index_interval = 2
and max_index_interval = 20;

更新3也尝试了

.setMaxRequestsPerConnection(HostDistance.LOCAL, 1)
.setMaxRequestsPerConnection(HostDistance.REMOTE, 1)

没有任何改变

Answer 1

最终我认为这将取决于你的代码在做什么。你能举个例子吗？

关于延迟的增加，你是如何衡量的？根据你的陈述：

奇怪的是，如果我让60个线程的应用程序运行，并在同一台机器上启动另一个只有1个线程的进程，那么单线程应用程序的提取时间又是5毫秒。

60个并发请求并不是太多，一般来说，不需要使用datastax java驱动程序对每个请求执行一个线程。您可以通过单个应用程序线程实现高吞吐量，因为驱动程序使用的netty事件循环组将完成大部分工作。

C*使用的本机协议允许每个连接有多个请求。正如您在这里配置的，每个连接最多可以有32768个并发请求。实际上，您根本不需要接触这个配置，因为默认（每个连接1000个请求）是明智的，因为在实践中，C*一次不会处理cassandra.yaml（128个默认）超过native_transport_max_threads的请求，并对其余的进行排队。

正因为如此，您不需要为每个主机建立许多连接。默认的每个主机1个核心连接应该足以满足60个并发请求。增加每个主机的连接数对您没有多大帮助，在html" target="_blank">分析中，我发现超过8个高吞吐量的主机连接（数千个并发请求）的收益递减，超过16个主机连接的吞吐量越来越差，尽管您的里程可能因环境而异。

综上所述，我建议不要在默认设置之外配置poolgoptions，除了在试图获得更高吞吐量的情况下将core和max设置为8之外(