Owen.Cai

in member function, can i write like this? .addStaticFunction("QueryTotalData", [](CCQLite3DB* pDB, char* pSQL, CCQLite3DBTable* pTable)->kaguya::CCQLite3DBTable_Warp { { kaguya::CCQLite3DBTable_Warp ret; if (!pDB->GetDataToTable(pSQL, pTable)) { return ret; } ret.m_pTmpTable = pTable; return...

> 还有一个问题是 ServiceBean 的 unexport 方法是谁调用的，理论上用户不会直接使用 ServiceBean 的，一般都是使用的 ReferenceConfig。如果 ServiceBean 的 unexport 是来自框架的调用，那么应该由外面的销毁管理器来统一清理。 这里有一个依赖关系是 ModuleModel => ConfigManager => ReferenceConfig，理论上是不应该由后级直接向前级直接发起调用的（一些特殊场景除外，但是要尽量减少这种场景），否则会很容易出现循环依赖。 我这边要做的就是service和ref的一个热加载的功能，service mesh里面控制面肯定也是需要这块的 1. 我原始是基于ServiceBean做export和unexport来实现的，我这边考虑改成用ServiceConfig去热加载服务，这样可以避开目前这个问题，我这边的实现这里应该是我用法问题 针对ServiceBean的代码增加我看了#8789 #8867 没有完全理解 1. 就是为什么不是加到自己成员的ModuleModel 2. ModuleModel...

> > 我这边要做的就是service和ref的一个热加载的功能，service mesh里面控制面肯定也是需要这块的 > > 这里在 3.0 的最新版本中，最好是和 ModuleModel 一起来做的，一次热发布绑定到 ModuleModel 的生命周期。目前 Spring Context 也支持绑定到 ModuleModel 上，在 Spring Context 关闭后也会自动关闭 ModuleModel，然后连带清理环境。当然单个的 Config 也是支持独立热发布的。 > > > ModuleModel => ConfigManager...

公司：杭州视洞科技有限公司 城市：杭州 邮箱：[email protected] 视洞在blurams的海外智能视频云平台，家庭智能视频开放云等平台全部从dubbo2.7.x升级到3.x，主要用到 1. triple用于标准化跨语言调用，实践mesh的方式 2. 应用级服务发现模型，降低万级服务器间消耗 3. 跨大洲，跨机房调用和数据同步（底层通信，泛型，序列化）

https://github.com/apache/dubbo-samples/pull/516 1. 增加使用基准测试的代码 dubbo版本3.1.0 jdk8和jdk17性能差距也非常大 > jdk17 grpc的unary单线程阻塞模式下： 8K ops/s tri的unary单线程阻塞模式下：4.6K ops/s grpc-client=>tri-server的unary单线程阻塞模式下： 6K ops/s > jdk8 grpc的unary单线程阻塞模式下：

1. 使用jprofile跑出来的火焰图耗时部分的优化效果不明显 2. @icodening 通过tcpdump发现碎包比grpc多几倍 结合以上两点得出结论基本的消耗应该都是在io层（使用网络层的部分代码） 基于 @icodening 的思路减少多次flush，合并flush的模式 > jdk17 tri的unary单线程阻塞模式下：5.7K ops/s grpc-client=>tri-server的unary单线程阻塞模式下： 7.5K ops/s

已经的准备提交的features 1. WriteQueue支持enqueueSoon模式（减少flush的次数） 2. Client里面的UNARY下去掉EndStreamQueueCommand，参考grpc在data的frame已经描述了endstream（服务端会少一次schedule调度） 今天做了几个测试 1. 服务端不使用SerializationExec线程，直接在Netty线程下做，效率从4500提升到6000左右（+40%），调度影响性能 2. tri client增加filter直接使用grpc代替底层的实现调用，性能基本4500提升到5600左右（+35%），如果把服务端换成grpc的实现还是可以到7500（基本等于grpc客户端调用grpc服务端），5500=>7500这部分应该是服务端的性能损失，结合1的情况，grpc一共两次调度，目前tri是3次调度，最后一次是无效的EndStreamQueueCommand

这边为止，使用frame来完成发送，client和server修改完成

1. 增加frame的处理逻辑 （1）去掉了endstream的包（最后一个数据包自己能描述） （2）信令优先级和数据优先级分离（frame的发送机制决定） （3）减少数据小包的发送量，分配的空间默认应该是4K，理论上都是满了才发送 a. 目前的发送时机 1. 满了发送 2. 手动flush 3. halfclose的时候发送并且endstream 2. QueueCommand全部改成直接使用Http2StreamFrame，理论上在eventloop只发送Http2StreamFrame，不处理其他构建的逻辑 4. 性能优化上，合并了3.2之后提升不明显，估计10%左右 目前单线程调用的性能大致从4500 => 6300，具体grpc的8000还是有差距

have same