Sogou|性能超群的HTTP服务器，搜狗C++服务器引擎发布
_原题为 性能超群的HTTP服务器 ， 搜狗C++服务器引擎发布
9月3日 ， 搜狗公司正式宣布开源C++服务器引擎——Sogou C++Workflow 。 目前Workflow支撑着搜狗几乎所有后端C++在线服务包括所有搜索服务 ， 云输入法 ， 在线广告等 ， 每日处理数百亿请求 ， 引擎一经发布就在 GitHub 上引起众多开发者关注 。 这款引擎不仅实现了高性能、轻量级的落地 ， 还创新性的引入任务流概念 ， 实现了计算任务与通信任务的统一和协同调度 。 基于Workflow引擎 ， 开发者可以方便的实现复杂的业务逻辑 ， 并进一步满足对高并发、高性能C++服务器程序的开发需求 。
GitHub搜索 Sogou C ++ Workflow即可找到该项目 。
轻量级、高性能 ，Sogou C++ Workflow助力企业降本增效
Workflow在设计之初 ， 就秉持着高性能与轻量级两个核心理念 。 长久以来 ， 业界中优化服务器性能都主要专注于如何跑满cpu、如何单独地让网络请求极速响应等方面 。 而此次上线搜狗Workflow则更专注于如何让各种网络资源被具体的调度器管理 ， 使其尽可能地全部调度起来 。
文章图片
另一方面 ， 对多通信计算资源融为一体的解决方案 ， 进一步提升了Workflow引擎的性能 。 过去开发者在面临选择高吞吐网络框架时 ， 需要自己面对不同计算资源比例而划分不同大小的线程池 。 然而每种计算具体资源需求比例是动态变化的 ， 重要性也不一样 ， 后端响应时长也是动态变动 。 如今在workflow的加持下 ， C++服务器引擎也能像Go语言一样 ， 实现网络资源异步调度 ， 并且进一步打通计算 ， 磁盘等资源 。
文章图片
引入任务流概念 ， 是搜狗Workflow引擎的另一亮点 。 Workflow将资源高度封装 ， 用户再也接触不到连接池、线程池、包括想要做aio时的文件fd与各种异步通知机制 。 这就意味着 ， 在开发阶段开发人员仅仅需要了解业务关系而不用关心内部细节 ， 帮助开发者们实现自己复杂的业务逻辑 。
开发人员可以利用Workflow封装好的各种任务来动态或静态组建自己的业务逻辑 ， 如下图所示 ， 不同类型的任务都可以被串行、并行到一起：
文章图片
除了各种创新设计以外 ， workflow还拥有比其他C++框架更友好的用户体验 。 过去许多企业自己搭建的服务器平台 ， 在设计之初并未考虑到对多平台、多协议的支持 ， 导致当新需求出现之时 ， 开发者不得不通过自定义框架等方式来解决这个问题 。 Workflow原生实现了对http、redis、mysql和kafka等协议 ， 可以直接作为这些协议的客户端使用 。 并且在其基础上开发了一套更加易用的Sogou RPC ， 实现与brpc和thrift互通 ， IDL支持protobuf和thrift ， 并且可以通过http+json或IDL实现跨语言 ， Sogou RPC项目也会在不久的将来开源 。
Http Server性能实测：Sogou C++Workflow VS nginx、brpc
为了充分的体现出Workflow在性能上的优势 ， 搜狗也提供了Workflow和nginx、brpc两个比较主流知名的系统一起做的http server性能对比 ，
测试环境：
这里选取了最基本的测试场景：wrk或者wrk2跨机做client ， 单server ， 长连接 ， CPU：40核 E5-2630 v4 @ 2.20GHz ， 内存：192GB ， 网卡：25000Mb/s 。 nginx配置了auto的进程数(与核数一致) ， brpc配置了40个nthreads ， workflow配置了16个poller线程和20个handler线程 。
测试一：不同并发数对QPS的影响(越高越好)
文章图片
结论：随着压测并发数的增加 ， server的QPS会随着增高 。 可以看到Workflow无论是低并发数还是高并发数的情况下 ， QPS依然比nginx和brpc要高 ， 尤其是并发数超过128的时候优势更加明显 ， Workfow对于小包基本能保证50w的QPS ， 说明内部对网络资源的高并发调度做了很多优化 。
测试二：不同数据大小对QPS的影响(越高越好)
文章图片
结论：此处的返回包大小是http请求的body大小 ， 随着返回包增大 ， QPS会有所下降 ， 我们希望QPS依然尽可能保持平稳不要下降得太快 。 Workflow在同并发下的性能依然比其他两个系统要好 ， 说明网络收发和其他调用之间的调度协调得更好 。
测试三：固定QPS下的延迟分布CDF图(越左越好 ， 越直越好)
文章图片
结论：本测试由wrk2进行固定QPS的压测 ， 其中还有1%的长尾请求Outiler ， 长尾请求不计入结果 ， 因为我们关注的是模拟真实情况下普通请求能否被及时处理 。 由于nginx在其他测试中性能略差一截 ， 因此没有对其进行CDF对比 。 可以看到在不同比例的分布中 ， Workflow的延迟更低、且最慢的那些(0.99到1.00之间)延迟增长也相对缓慢 ， 说明Workflow对长尾处理更及时 。
推荐阅读
- https://p.ssl.img.360kuai.com/t0173ca76e37f2fabaa.jpg?size=640x381?size=640x381|无力的人间：脑瘫家庭的痛苦与挣扎
- |性能超群的HTTP服务器，搜狗C++服务器引擎发布