Ye Tian

1. 是直连，是长链接。 2. m 个 client，n 个 tabletserver，极端情况下，每个 tabletserver 维护 m 条链接，每个 client 维护 n 条链接，整体 overhead 不高，m，n 数量级通常不超过 k 级别 3. 踢节点不是 sdk 做的，是 master 做的，zk 掉节点是其中一种场景，master 和 ts...

统一回复下，因为2.9的tera依赖改动后的sofa-pbrpc，所以编译挂了。 rpc那边的pr我明天修改后重新提一下。

我理解 brpc 的 prometheus 是用来传输自己的 metric 信息的，而不是一套公开的机制，因此是不是对 counter summary 这些东西并没有什么需求，其实就是一堆统计信息

brpc + dpdk 我们基于 f-stack 在内部做过一版 demo 验证。在 brpc 使用的 protobuf 协议 + 本身的 overhead 场景下，引入 dpdk 仅仅能带来不到 30% 左右的性能提升，主要提升来自于 bypass kernel network stack ，但是这本身不是 brpc 本身的瓶颈。考虑到引入 user-space network stack...

@jamesge 根据 perf 结果来看，CPU 开销很大部分在 protobuf 和 bvar 那些监控上面，我们也尝试过把 bvar 什么的都删除，然后仅保留 protobuf 和 dpdk 这样的 “极简模式”，单核性能提升 80% 左右。业内类似 erpc 这种，通过 dpdk 把吞吐打得特别高的，一般都是没有结构化的信息，或者一个极其简单的结构化信息，如果能把 protobuf 整个拿掉，可能效果会更明显一些。

@colin2328 Hi, as I also encountered the same problem, and after searching some issues, I found that the grad can be provided in dense compute kernel. But I think dense...

I found one way is to implement my own Sharder ```python class EmbeddingCollectionSharderDense(EmbeddingCollectionSharder): def compute_kernels(self, sharding_type: str, compute_device_type: str) -> List[str]: return super().compute_kernels(sharding_type, compute_device_type) + [EmbeddingComputeKernel.DENSE.value] ```

@henrylhtsang Hi, thank you, but I think dense compute kernel was disabled here: https://github.com/pytorch/torchrec/commit/35c05fa00d2ca7e7b6fd577374560a5174be2675#diff-72b4a4f205f4de558b2f5731a6697ae80483ee532eb2012d59999e5d7c462200L302-R302 which means Dense kernel was no longer a valid option for non-data-parallel module.

What I mean by 'disable' is that it can no longer be used with sharding modules.

@henrylhtsang Sorry for the late reply, maybe you can try this script with a gpu machine: ```python #!/usr/bin/env python # coding: utf-8 # In[1]: import os import torch import torchrec...