Chinaunix

标题: 谁在商业上面上用过asio，性能怎么样？ [打印本页]

作者: lims_xlh 时间: 2015-06-02 11:59
标题: 谁在商业上面上用过asio，性能怎么样？
本帖最后由 lims_xlh 于 2015-06-02 17:05 编辑

大家有在商业项目用过asio吗，性能怎么样，我们项目中用的asio感觉性能不怎么样啊，跟asio底层队列的锁有关系吗

举个例子：
假设有个两个模型：
A client-->mysql
B client-->proxy-->mysql
1）A，B都是接收m个连接，并且接收n个sql
2）mysql 建立一个thread需要x 毫秒，执行一个sql的逻辑过程y毫秒，sql在代理内的执行时间z毫秒
对于只是用mysql的的情况来说：
mysql需要针对m个连接建立m个线程，并且执行n个sql，所以时间应该是mx+yn毫秒
但是对于代理来说，mysql的连接是早就建立好了的长连接，所以这块的耗时忽略，他的时间是：
mysql执行n个sql的时间和 n个sql在代理内部业务逻辑的时间：ny+nz
所以那个时间快慢就是取决于mx 和 nz的大小了。
在并发量特别高的情况下，m会特别大，但是每个连接都执行有限的sql，n特别小，这时候mx>nz
但是我的代理还是没跑过mysql，从理论上看应该是z特别大。

作者: fender0107401 时间: 2015-06-02 12:09
本帖最后由 fender0107401 于 2015-06-02 12:09 编辑

我在半生产环境用过，感觉挺好，但是我这边对asio的压力比较低。

作者: lims_xlh 时间: 2015-06-02 12:20
你是什么场景，我这边是搞了一个mysql的代理，asio+coroutine的，效果不是太理想，在并发比较低的情况下比mysql快不了多少

作者: fender0107401 时间: 2015-06-02 13:07
回复 3# lims_xlh

我这边是cs构建的一个小系统，服务器端和客户单用asio进行各种通信，通信的频率不高。

作者: windoze 时间: 2015-06-02 13:57
回复 3# lims_xlh

mysql代理在什么情况下能比mysql快呢？

作者: longshadian 时间: 2015-06-02 14:17
boost.asio应该性能因该不错吧，百度有个开源库sofa-pbrpc，内部用asio实现。据说在百度内部广泛使用。

作者: lims_xlh 时间: 2015-06-02 14:58
回复 5# windoze

应该是大并发的情况吧：因为代理有socket复用，但是mysql是一个连接一个线程，大并发的情况代理应该是快的。

作者: lims_xlh 时间: 2015-06-02 15:01
回复 6# longshadian

多谢，看一下他的实现

作者: hellioncu 时间: 2015-06-02 15:08

lims_xlh 发表于 2015-06-02 14:58
回复 5# windoze

我想他问你应该是认为两者不是一码事，怎么比较

作者: lims_xlh 时间: 2015-06-02 15:08
回复 5# windoze

看了下asio代码，我是一个线程一个io_service,每个线程应该是一个op队列，应该不会有锁的争用问题，不知道那个地方用的不对？

作者: lims_xlh 时间: 2015-06-02 15:10
回复 9# hellioncu

恩，我说的可能是不太清楚，我指的是前端访问mysql 速度跟访问代理速度的对比。

作者: linux_c_py_php 时间: 2015-06-02 15:35
我用过asio，可以跑满万兆网卡，所以网络性能层面应该没有什么问题。

作者: windoze 时间: 2015-06-02 15:41
回复 10# lims_xlh

每线程一个io_service还会有什么争用呢？瓶颈肯定不在这里，拿一个io_service给8个线程共享也没有太明显的瓶颈。

我的问题是你写了个程序做mysql代理，这个代理怎么可能比mysql更快呢？它自己再快还不得卡在mysql那头？

作者: lims_xlh 时间: 2015-06-02 15:53
本帖最后由 lims_xlh 于 2015-06-02 16:00 编辑

回复 13# windoze

举个例子：
假设有个两个模型：
A client-->mysql
B client-->proxy-->mysql
1）A，B都是接收m个连接，并且接收n个sql
2）mysql 建立一个thread需要x 毫秒，执行一个sql的逻辑过程y毫秒，sql在代理内的执行时间z毫秒
对于只是用mysql的的情况来说：
mysql需要针对m个连接建立m个线程，并且执行n个sql，所以时间应该是mx+yn毫秒
但是对于代理来说，mysql的连接是早就建立好了的长连接，所以这块的耗时忽略，他的时间是：
mysql执行n个sql的时间和 n个sql在代理内部业务逻辑的时间：ny+nz
所以那个时间快慢就是取决于mx 和 nz的大小了。
在并发量特别高的情况下，m会特别大，但是每个连接都执行有限的sql，n特别小，这时候mx>nz

作者: linux_c_py_php 时间: 2015-06-02 15:59

lims_xlh 发表于 2015-06-02 15:53
回复 13# windoze

瓶颈不在于短连接，这种优化理由不科学。

作者: lims_xlh 时间: 2015-06-02 16:12
回复 15# linux_c_py_php
短连接可以减少mysql的压力

作者: starwing83 时间: 2015-06-02 16:33
回复 15# linux_c_py_php

Hi~ 好久没看到你了哈= =

最近做了一个C/C++11的网络库，在这里：https://github.com/starwing/znet

帮我review下？

作者: yulihua49 时间: 2015-06-02 17:20
本帖最后由 yulihua49 于 2015-06-02 17:21 编辑

lims_xlh 发表于 2015-06-02 11:59
大家有在商业项目用过asio吗，性能怎么样，我们项目中用的asio感觉性能不怎么样啊，跟asio底层队列的锁有关 ...

我从来不认为ASIO能有多少性能。主要是在少线程系统，应对大量客户端（任务），减少线程无谓的等待，利用这段时间为别的任务服务，可以改善客户体验（减少平均响应时间）。
性能嘛，只能说还可以。

作者: lims_xlh 时间: 2015-06-02 17:41
回复 18# yulihua49
那这样的话对于整个系统的平均时延也是应该降低的把，因为可以在用户空间最大限度的利用cpu做更多的事情吧，
但是我代理平均时延也没跑过mysql，用valgrind也没看出有什么地方有瓶颈。

作者: yulihua49 时间: 2015-06-02 19:25
本帖最后由 yulihua49 于 2015-06-02 19:27 编辑

lims_xlh 发表于 2015-06-02 17:41
回复 18# yulihua49
那这样的话对于整个系统的平均时延也是应该降低的把，因为可以在用户空间最大限度的利 ...

不清楚sql代理的过程。
我是在文件传输＋交易混合服务器系统。
一个或几个任务传输大文件，SIO就会长时间占死线程，其它交易请求被耽误，响应时间极长。使用ASIO后，不管多少个任务在传输文件，交易请求都会立即响应。
但是对于传输文件的任务，它的时间肯定变长了。
如果计算混合任务的平均响应时间，肯定大大缩短了。

作者: lims_xlh 时间: 2015-06-02 19:34
回复 20# yulihua49

你说这请求响应快应该是没有问题，因为asio是处理完了io之后回调，所以会立刻响应新的请求，
不知道你的一个完整请求的时长关注过没有，是增加了还是比以前的减少了

作者: yulihua49 时间: 2015-06-02 21:12

lims_xlh 发表于 2015-06-02 19:34
回复 20# yulihua49

增加了。但增加的不多。

作者: linux_c_py_php 时间: 2015-06-04 10:08

starwing83 发表于 2015-06-02 16:33
回复 15# linux_c_py_php

作者: starwing83 时间: 2015-06-08 17:02
本帖最后由 starwing83 于 2015-06-08 17:03 编辑

linux_c_py_php 发表于 2015-06-04 10:08

现在还在开发阶段，之前弄好了buffer，现在还缺select实现和Lua绑定，做好了以后就来论坛正式发布，恩~

最近刚刚做了bench，本地洪水测试能到23W请求每秒，echo是11W，带buffer的echo实现（支持即时发送和数据包回调）是9W。

作者: wlmqgzm 时间: 2015-10-27 18:50
我做的网络服务器用ASIO做, 在双核奔腾CPU上跑, 大约32万QPS ECHO, 性能超强.

作者: yulihua49 时间: 2015-10-27 20:15
本帖最后由 yulihua49 于 2015-10-27 20:28 编辑

windoze 发表于 2015-06-02 13:57
回复 3# lims_xlh

mysql代理在什么情况下能比mysql快呢？

mysql要有连接池。连接数为最佳连接数。请求的前端用户数很多，大大超过数据库连接数。
他们的请求在代理器里排队。
有序的排队，效率大大超过无序的竞争。尤其是有锁的情况（像铁路抢座），大家一起撞锁，响应会非常慢。一小波一小波的放进去抢，会好很多。
也就是所谓“适度并行”。

作者: windoze 时间: 2015-10-27 20:30
回复 26# yulihua49

但这样依然不会比MySQL快啊？最多就是负载能力比单个MySQL强而已。

作者: yulihua49 时间: 2015-10-27 20:35
本帖最后由 yulihua49 于 2015-10-27 21:00 编辑

windoze 发表于 2015-10-27 20:30
回复 26# yulihua49

但这样依然不会比MySQL快啊？最多就是负载能力比单个MySQL强而已。

我们不说单个的响应时间，考察整体的交易吞吐量。
平均响应时间也会减小。在超量的无序竞争中被卡住是很惨的，比排队惨得多，你如果挤过公交估计有体会。
如果数据库的最佳并行度是50，我一次放进去50.以后出来一个放进一个。性能肯定是最高的。
如果10000个人来抢，排队的优势就非常高。
如果真的放10000个链接进入数据库，而且竞争起来的话，估计数据库就瘫了。

单纯的代理优势有限，如果代理换成中间业务服务器，以事务为单位与前端交互。业务服务器与后端数据库，每取得一次链接完整的做一个事务是最高效的。
就是前端每次请求一个事务，事务做完服务器给一个总的应答。
不要一个个SQL的请求，有时后端的连接池没法处理。
比如：
cursor=prepare(...); //返回游标。但是后端的数据库连接池释放了。
fetch(cursor); // 再次申请的数据库连接，还是原来的那个？cursor有效吗？
。。。。。

作者: windoze 时间: 2015-10-27 21:18
回复 28# yulihua49

我知道你的意思，但即便如此你也只能说负载能力强吞吐量高，就每一个请求的处理速度而言，代理肯定会更慢，想想就知道这是废话，中间多经过了一级当然会更花时间。

我不是否定代理的好处，但如果你注重的是单个请求的处理时间，代理不是个好解决方案；如果你注重的是总体吞吐量负载能力并发数什么的另说。

作者: wlmqgzm 时间: 2015-10-28 10:53
本帖最后由 wlmqgzm 于 2015-10-28 10:56 编辑

mysql代理在什么情况下能比mysql快呢?

我说一种情况, 就是mysql代理进行读写分离,

1) 读服务器比较闲, 主服务器比较忙.
2) 读数据可能在本地cache上有缓存,

这2种情况都比mysql快.

作者: wlmqgzm 时间: 2015-10-28 10:59
回复 28# yulihua49

支持这种说法, 确实, 如果并发量非常大的话, 在mysql前端做代理层, 会大幅度减少服务器压力, 最终减少每个请求的平均响应时间, 这个思路很正确.

作者: yulihua49 时间: 2015-10-29 14:17

windoze 发表于 2015-10-27 21:18
回复 28# yulihua49

我知道你的意思，但即便如此你也只能说负载能力强吞吐量高，就每一个请求的处理速度 ...

如果并发量小就没必要中间层。

作者: windoze 时间: 2015-10-29 14:24
本帖最后由 windoze 于 2015-10-29 14:25 编辑

回复 30# wlmqgzm

做读写分离提高了写入的开销；做cache降低了一致性的保证。

每种收益都有成本，就看你愿不愿意付。

回复 32# yulihua49

然而这就是另外一个问题了。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)