benchmark的代码在哪里？ about workflow

[holmes1412]

这里可以附上昨天文章里的任务流例子哈～其中不同颜色的节点是不同的资源任务，包括文件io、网络io、计算任务和计时器，这些都可以通过简洁的接口创建并串到一起～

我们工作中面临的任务流程图往往非常复杂、并且常常需要动态去构建。这些workflow都已经很好地支持了～下一步是比如如何让程序分支进一步抽象成任务流、以及DAG的任务抽象等等都是我们在思考的事情～

[Barenboim]

你好，benchmark测试源代码和更多测试数据，我们努力今天放上来。也希望大家帮我们提供更多实测的性能对比。另外我们也还优化代码，之后性能还会提升。
至于asio的事情😂。情况是这样的，这个项目并不是一时头脑发热从头开始设计，而是搜狗搜索10多年技术积累慢慢形成的一个项目。没有引入asio和boost主要还是因为搜狗搜索技团队的风格习惯问题，没有什么特别的原因（开始也不考虑跨平台）。代码里也有很多old-fashion的C++风格大家可以继续吐槽。
不过项目确实做到满足公司大多数后端开发的需求了，各业务线都用得很开心。另外不使用asio有一个直接的好处，就是代码编译速度快很多，对于网页搜索里那些代码量巨大的项目，还是很重要的。
BTW，kafka client的代码我们也很快合并进来，这是一个很优秀的C++ kafka实现。

[westfly]

https://github.com/holmes1412/sogou-rpc-benchmark
在readme中有

[qicosmos]

@westfly 只看到测试结果，并没有看到源码呀？

[holmes1412]

@qicosmos hi，我们做了两组benchmark：
第一组是作为http server和nginx和brpc对比的，这个是用wrk/wrk2测试的～图片和文字描述昨天发了文章，今天会补充到github上；
第二组是小伙伴给的链接，感谢 @westfly ～这个是基于workflow做的sogou rpc项目，整体项目还没github上开源，但也马上与大家见面啦～欢迎关注，如果对srpc感兴趣可以先直接联系我，多多交流😉

[qicosmos]

Good

[qicosmos]

BTW，不用asio可惜了

[holmes1412]

为什么可惜呀？我们就是做了asio的事情，其中Communicator层是可以单独拿出来做通信器的，性能也非常好～
另外一点需要自己的封装的原因是在于，我们的设计是一切的异步资源，需要自己写子任务调度才能打通上层任务流，让不同类型的资源串到同一个DAG图里～
所以不需要也不能用asio👻

[qicosmos]

换句话说asio已经做了这些事情，而且asio本身是跨平台的，如果基于asio开发，根本不用考虑支持多个操作系统的问题了，asio的异步模型也很优秀，而且asio也已经支持了task和executor。

[qicosmos]

c++新标准正在做executor的标准化的工作，建议你们自己写的executor参考一下标准库的提案去做会更好。

[holmes1412]

感谢分享～C++ executor标准化我们会仔细参考下～☺️

刚才说的asio一个是不需要，是因为我们已经有对应的实现了：

1. 性能会更好；（目前也并没有看到brpc等换asio）
2. 调度不基于协程是自己设计的多队列，满足我们的调度需求；
3. 具体协议也是我们基于当前通信器接口自己解析的，不需要依赖hiredis、libmysql、librdkafka等～
   那么我们为什么要换呢？

第二个是不能用。asio的task我看了下与完整的任务流还有一些差距，如果方便的话可以分享一下如何做(A)->((B) (C))->(D)的例子～目前workfow为了封装建任务流和提供简洁接口，做了很多事情，“任务流可以结合具体资源”是我看了目前其他系统所没有的优点～

我个人比较相信任何能解决大家痛点的框架设计在将来都会被合入语言层面～executor和task可以被C++提供体验友好的使用方式也是指日可待的

[qicosmos]

希望你们做得更好。

[qicosmos]

感谢分享～C++ executor标准化我们会仔细参考下～☺️

刚才说的asio一个是不需要，是因为我们已经有对应的实现了：

1. 性能会更好；（目前也并没有看到brpc等换asio）
2. 调度不基于协程是自己设计的多队列，满足我们的调度需求；
3. 具体协议也是我们基于当前通信器接口自己解析的，不需要依赖hiredis、libmysql、librdkafka等～
   那么我们为什么要换呢？

第二个是不能用。asio的task我看了下与完整的任务流还有一些差距，如果方便的话可以分享一下如何做(A)->((B) (C))->(D)的例子～目前workfow为了封装建任务流和提供简洁接口，做了很多事情，“任务流可以结合具体资源”是我看了目前其他系统所没有的优点～

我个人比较相信任何能解决大家痛点的框架设计在将来都会被合入语言层面～executor和task可以被C++提供体验友好的使用方式也是指日可待的

asio性能也非常好的。
调度算是框架层的东西了，至于用协程还是其他调度库不是asio的事，asio只提供基础的异步通信框架。
至于协议也是用户基于asio之上去封装的，和asio本身没关系。

原谅我忍不住杠精一下，我只是想澄清一些东西：）

[sonullx]

@qicosmos

你好，我们刚刚更新了一部分benchmark内容，文档在docs/benchmark.md，对应的代码在benchmark目录下，欢迎阅览。

更多的测试我们还在整理中，后续也会更新。

感谢关注。

[qicosmos]

谢谢。
关于测试代码，openssl导致编译错误，能不能在cmakelists文件中设置一个开关，可以禁用opensssl，让测试和使用更方便？

[Barenboim]

谢谢。
关于测试代码，openssl导致编译错误，能不能在cmakelists文件中设置一个开关，可以禁用opensssl，让测试和使用更方便？

这件事情工作量有点大，我们想想怎么弄。编译阶段就禁了SSL可能还对性能有一点点帮助。现在这个编译问题我们先看看。感谢！

[qicosmos]

是的，你们不会默认都是ssl的吧？

[Barenboim]

是的，你们不会默认都是ssl的吧？

后端服务器之间肯定都不是ssl。确实我们主要做高性能后端的话，ssl不是重点。没加编译选项有几个原因，一方面太多ifdef不太好看，另外就是担心头文件和lib不一致导致一些错误。这也是纯.h发布的好处，可惜我们不是啊😥

[qicosmos]

关于这里你们可以参考asio的抽象，将ssl和非ssl的stream抽象得很好，对于asio来说禁用ssl就是几行代码的事情。asio也是header only的。

[Barenboim]

关于这里你们可以参考asio的抽象，将ssl和非ssl的stream抽象得很好，对于asio来说禁用ssl就是几行代码的事情。asio也是header only的。

嗯嗯，下午貌似在你的网站上看到相关的介绍，之后我多研究一下asio。感谢建议。我们的项目也很有意思，比较经典的OO设计，接口上也很方便。可以试一试噢。

[qicosmos]

没问题，以后可以多切磋。

[jovany-wang]

@holmes1412
我认为asio与否是通信层的考量而不是调度层的考量。这两者只是一种单向依赖关系。前面提到的不同节点不同颜色的workflow我理解跟通信是无关的。

[jovany-wang]

3. 具体协议也是我们基于当前通信器接口自己解析的，不需要依赖hiredis、libmysql、librdkafka等～

对于这一点，我也有点怀疑保留态度：
(1) 如果要支持一个client就需要用实现该协议，那么对于后续增长的工作量将是巨大的。
(2) 协议升级带来的维护问题： 稳定的产品协议多是兼容且稳定的，但是也不能避免0升级，那么带来的问题就是协议升级了，我们这边还不清楚，导致升级跟不上，因为维护的客户端种类太多了。

在asio进入标准库之后，任何产品的C++ client肯定都得支持标准库的实现，这样的话，上述的问题就能避免，而且避免造无用的轮子问题。

[jovany-wang]

另外需要点赞的是 项目的出发思路以及要致力于解决的问题是很棒的。

[Barenboim]

3. 具体协议也是我们基于当前通信器接口自己解析的，不需要依赖hiredis、libmysql、librdkafka等～

对于这一点，我也有点怀疑保留态度：
(1) 如果要支持一个client就需要用实现该协议，那么对于后续增长的工作量将是巨大的。
(2) 协议升级带来的维护问题： 稳定的产品协议多是兼容且稳定的，但是也不能避免0升级，那么带来的问题就是协议升级了，我们这边还不清楚，导致升级跟不上，因为维护的客户端种类太多了。

在asio进入标准库之后，任何产品的C++ client肯定都得支持标准库的实现，这样的话，上述的问题就能避免，而且避免造无用的轮子问题。

自己解析协议的问题，我们是有一些考量的。http就不说了。像mysql，kafka，市面上并没有很好的协议与通信分离的实现，可以方便嵌入我们的通信引擎。比如mysql的官方客户端，就是个全同步的接口，不太好与我们的结合。kafka协议，c/c++的实现比较有名的是rdkafka，但我们就是觉得它不好用才自己做的啊，而且rdkafka也没办法结合到我们的任务模型里。redis的话，可以用hiredis，但我们的工程师顺手就做了😂
协议实现上，我们不求面面俱到，原则上只解决需要用到的问题，比如mysql只做了query命令，这个命令几乎可以实现一切的操作了。
kafka协议我们和rdkafka一样，会自动检测broker版本什么的。当然有一些功能还不完整，之后再慢慢添加。我们的目标就是用户可以只把我的当kafka client来使用，并且做成市面上最好的C++ kafka client。
redis的话。。。没什么好说的。用户也可以只把我的当redis client来用。但redis pipeline client这个我们一直没给加上。
感谢大家的建议。大家可以实际用一下，可能会更加理解我们自己做的原因。
BTW，我们还做了全功能的thrift idl编译器支持thrift协议的rpc。敬请大家期待srpc项目。

[jovany-wang]

@Barenboim 非常能理解项目的发展历史过程。 我也是从自己的理解出来去看这个问题，也有一定自己的局限性。

[qicosmos]

有点遗憾的是你们大量的使用裸指针，包括用户接口部分，这是不安全的，既然用了现代c++，应该尽量用智能指针。

[Barenboim]

有点遗憾的是你们大量的使用裸指针，包括用户接口部分，这是不安全的，既然用了现代c++，应该尽量用智能指针。

项目用到现代C++的地方少，必须掌握也就function和move。我最大的遗憾还是11没有any，有几处用户接口用了void *，导致和现代c++的结合不太自然。后面我们再做上面的生态项目的话，代码风格会现代一些。
这个项目就当纪念一下传统OOP吧。

[qicosmos]

有点遗憾的是你们大量的使用裸指针，包括用户接口部分，这是不安全的，既然用了现代c++，应该尽量用智能指针。

项目用到现代C++的地方少，必须掌握也就function和move。我最大的遗憾还是11没有any，有几处用户接口用了void *，导致和现代c++的结合不太自然。后面我们再做上面的生态项目的话，代码风格会现代一些。
这个项目就当纪念一下传统OOP吧。

怎么说呢，裸指针永远是不安全的，非常容易埋坑，我觉得算是技术债务，如果精力，人力都够的话建议重构一下。
关于any或者variant其实可以用boost的，还可以考虑用absl库的any, 都是不错的。现在改都来得及，只要去做就永远也不晚:)

[Barenboim]

有点遗憾的是你们大量的使用裸指针，包括用户接口部分，这是不安全的，既然用了现代c++，应该尽量用智能指针。

项目用到现代C++的地方少，必须掌握也就function和move。我最大的遗憾还是11没有any，有几处用户接口用了void *，导致和现代c++的结合不太自然。后面我们再做上面的生态项目的话，代码风格会现代一些。
这个项目就当纪念一下传统OOP吧。

怎么说呢，裸指针永远是不安全的，非常容易埋坑，我觉得算是技术债务，如果精力，人力都够的话建议重构一下。
关于any或者variant其实可以用boost的，还可以考虑用absl库的any, 都是不错的。现在改都来得及，只要去做就永远也不晚:)

any的事肯定会想办法改。或者17流行了之后我们直接加上。
裸指针的安全性问题，就看怎么理解安全的定义了。搜索引擎项目，有自己的特点，很多事情做法不太一样，这个问题要讨论起来就太复杂了。欢迎大家各种拍砖，但尽量避免流派之争，我们最终目的还是为了解决实际问题不是？

[qicosmos]

有点遗憾的是你们大量的使用裸指针，包括用户接口部分，这是不安全的，既然用了现代c++，应该尽量用智能指针。

项目用到现代C++的地方少，必须掌握也就function和move。我最大的遗憾还是11没有any，有几处用户接口用了void *，导致和现代c++的结合不太自然。后面我们再做上面的生态项目的话，代码风格会现代一些。
这个项目就当纪念一下传统OOP吧。

怎么说呢，裸指针永远是不安全的，非常容易埋坑，我觉得算是技术债务，如果精力，人力都够的话建议重构一下。
关于any或者variant其实可以用boost的，还可以考虑用absl库的any, 都是不错的。现在改都来得及，只要去做就永远也不晚:)

any的事肯定会想办法改。或者17流行了之后我们直接加上。
裸指针的安全性问题，就看怎么理解安全的定义了。搜索引擎项目，有自己的特点，很多事情做法不太一样，这个问题要讨论起来就太复杂了。欢迎大家各种拍砖，但尽量避免流派之争，我们最终目的还是为了解决实际问题不是？

这个可不是流派之争，c语言的安全性本来就比c++弱很多的，既然用了c++就应该用c++新特性让代码变得更安全，关于编写安全代码，我之前在purecpp分享过一篇文章：http://purecpp.org/detail?id=2189

裸指针是真的不安全，很容易掉坑里。c++20已经完成了，后面可以一步到位升级到c++20：）

[Barenboim]

有点遗憾的是你们大量的使用裸指针，包括用户接口部分，这是不安全的，既然用了现代c++，应该尽量用智能指针。

项目用到现代C++的地方少，必须掌握也就function和move。我最大的遗憾还是11没有any，有几处用户接口用了void *，导致和现代c++的结合不太自然。后面我们再做上面的生态项目的话，代码风格会现代一些。
这个项目就当纪念一下传统OOP吧。

怎么说呢，裸指针永远是不安全的，非常容易埋坑，我觉得算是技术债务，如果精力，人力都够的话建议重构一下。
关于any或者variant其实可以用boost的，还可以考虑用absl库的any, 都是不错的。现在改都来得及，只要去做就永远也不晚:)

any的事肯定会想办法改。或者17流行了之后我们直接加上。
裸指针的安全性问题，就看怎么理解安全的定义了。搜索引擎项目，有自己的特点，很多事情做法不太一样，这个问题要讨论起来就太复杂了。欢迎大家各种拍砖，但尽量避免流派之争，我们最终目的还是为了解决实际问题不是？

这个可不是流派之争，c语言的安全性本来就比c++弱很多的，既然用了c++就应该用c++新特性让代码变得更安全，关于编写安全代码，我之前在purecpp分享过一篇文章：http://purecpp.org/detail?id=2189

裸指针是真的不安全，很容易掉坑里。c++20已经完成了，后面可以一步到位升级到c++20：）

哈哈，好的我先看看你们的文章。太现代我们编译时间也耗不起啊😂

[qicosmos]

放心吧，越现代编译越快，newer is better, 拥抱新标准，让你们的代码简洁，更安全，更高效：）

[qicosmos]

BTW，希望你们在合适的时候可以把我用c++17和asio写的一个header only的http server--cinatra也做一下pk吧。

[Barenboim]

BTW，希望你们在合适的时候可以把我用c++17和asio写的一个header only的http server--cinatra也做一下pk吧。

你那个项目我有看。感觉纯跑qps我们干不过呀，但加上长尾请求可能我们的会好一些。等之后看实测数据。
我们的结果要过一遍消息队列，还是带锁的，已经决定了我们的上限QPS了。

[Barenboim]

BTW，希望你们在合适的时候可以把我用c++17和asio写的一个header only的http server--cinatra也做一下pk吧。

"Hello World"长连接你的是我们20倍速度，短连接是我们1/2不到。加上慢请求你的没法测，按你某个demo的方法结果应该非常难看，就不试了。
以后我们尽量不惹个人作品...

[qicosmos]

hi 可以把短链接和慢请求的测试方法发出来吗，慢请求之类的可以放到线程池中去处理的，cinatra支持异步去处理请求的，如果你还是用直接返回的方法去测试慢请求之类做那肯定qps上不去，针对不同的场景需要做不同的优化。
另外可以把你们短链接和慢请求的测试方法发出来吗？

[qicosmos]

BTW，希望你们在合适的时候可以把我用c++17和asio写的一个header only的http server--cinatra也做一下pk吧。

"Hello World"长连接你的是我们20倍速度，短连接是我们1/2不到。加上慢请求你的没法测，按你某个demo的方法结果应该非常难看，就不试了。
以后我们尽量不惹个人作品...

应该是你cinatra用法不太对，还是希望把测试方法明确一下，我也测测：）

[Barenboim]

短连接测试server端代码配置没有区别，只是wrk加了Connection: close。WFHttpServer会识别这个，回复完成直接关闭socket。如果cinatra不识别http header的话则比我们多处理一次网络事件，慢的话可以理解。
慢请求我们没有实验。我重新看了你的demo，应该cinatra的响应时间分布也不会差。但我们用法简单很多呢：）

[qicosmos]

短连接测试server端代码配置没有区别，只是wrk加了Connection: close。WFHttpServer会识别这个，回复完成直接关闭socket。如果cinatra不识别http header的话则比我们多处理一次网络事件，慢的话可以理解。
慢请求我们没有实验。我重新看了你的demo，应该cinatra的响应时间分布也不会差。但我们用法简单很多呢：）

cinatra会识别http header的，是在header里设置了connection:close吧，wrk测试就好说，我晚点测测看咯。另外你说的用法简单很多是啥意思，什么的用法简单很多，

[Barenboim]

短连接测试server端代码配置没有区别，只是wrk加了Connection: close。WFHttpServer会识别这个，回复完成直接关闭socket。如果cinatra不识别http header的话则比我们多处理一次网络事件，慢的话可以理解。
慢请求我们没有实验。我重新看了你的demo，应该cinatra的响应时间分布也不会差。但我们用法简单很多呢：）

cinatra会识别http header的，是在header里设置了connection:close吧，wrk测试就好说，我晚点测测看咯。另外你说的用法简单很多是啥意思，什么的用法简单很多，

指异步server的写法简单。

[qicosmos]

短连接测试server端代码配置没有区别，只是wrk加了Connection: close。WFHttpServer会识别这个，回复完成直接关闭socket。如果cinatra不识别http header的话则比我们多处理一次网络事件，慢的话可以理解。
慢请求我们没有实验。我重新看了你的demo，应该cinatra的响应时间分布也不会差。但我们用法简单很多呢：）

cinatra会识别http header的，是在header里设置了connection:close吧，wrk测试就好说，我晚点测测看咯。另外你说的用法简单很多是啥意思，什么的用法简单很多，

指异步server的写法简单。

OK， 我也看看你们的异步是怎么简单的。