提问参考模版：
由于有大量查询的需求，想尽可能的提高查询的并发度，想问下：
num_accept_threads这个参数的具体的含义，官网给的解释是“接受进入连接的线程数”，没明白。是指java-client的AsyncGraphClient.class或者GraphClient.class链接grpahd的线程数？那为什么默认值是1呢，只有一个线程能链接吗？
调节num_accept_threads可以提高并发度吗？
还有num_worker_threads这个参数，是否可以提高并发度？
num_accept_threads会影响新建连接.thrift是accept thread接收到连接之后，交给worker线程去处理的(num_worker_threads).
没明白你的意思
num_accept_threads 为什么默认值是1，，，，可以配置其他值吗？其含义是？
num_accept_threads 这个参数你不需要做任何修改，假如你是要性能调优，你可以关注下graphd这两个参数，num_netio_threads， num_worker_threads 现在默认就是按照cpu数的。
单机部署的nebula，在进行高并发查询测试时，发现CPU利用率很低，CPU利用率不到100%(测试物理机有24核)，您说的上面两个参数都已经调成CPU的个数，但是似乎没有生效，请问这正常吗
你是怎么个测试过程，客户端并发是多少，query又是怎样的？
使用jmeter压测工具进行测试的，其中用到了studio进行中转请求，并发分别测试了10,50,100，query语句是最短路径查询：find shortest path from id1 to id2 over * upto 5 steps | limit 1000; 客户端并发数上来了，但是单机的CPU利用率没有上升。
你这个测试query应该会扎堆在同个partition做排队，你可以看下磁盘使用情况，还有用perf 看下graph和stoarge的系统调用情况。
好的，我先看下，如果是这样的话，请问应该如何调整呢