graphd 的线程模型可以理解成一个大的线程池，所有 query 的任务都是丢入这个线程池，通过异步的方式来执行并返回结果。
graphd 最大能支持的并发数取决于你为其配置的最大线程数，即上述线程池的大小，如果不设置（默认0）则使用 cpu 核心数。
graphd 和 storaged 的通信是通过 thrift 的 RPC 来实现，是使用的单线程还是多线程取决于当前 query touch 到的 partition 数量，如果是涉及到多个 partition，那么 graphd 在向 storaged 请求数据时，会同时向对应 partition 的 leader 发送请求，并汇总结果给前端。
storaged 的并发度也是可以通过 gflags 配置的，但是一般不建议直接修改该值。现在每个 partition 的数据只能通过 leader 读取和写入，所以在 storaged 这边没有加锁，而是通过排队的方式来处理所有的请求。
上面你的一个 query 的返回结果很大，怀疑是当前的查询阻塞了后面的写入的请求，因为query请求时间较长，多个相同 query 同时请求就将 storaged 的 worker 线程耗尽，阻塞了后面的所有请求。
现在 storaged 还没有完成资源隔离的实现，后面会提供更好的优化策略，感谢您的反馈。