誰(shuí)在商業(yè)上面上用過(guò)asio，性能怎么樣？

lims_xlh

大家有在商業(yè)項(xiàng)目用過(guò)asio嗎，性能怎么樣，我們項(xiàng)目中用的asio感覺(jué)性能不怎么樣啊，跟asio底層隊(duì)列的鎖有關(guān)系嗎

    舉個(gè)例子：
    假設(shè)有個(gè)兩個(gè)模型：
    A  client-->mysql
    B  client-->proxy-->mysql
    1）A，B都是接收m個(gè)連接，并且接收n個(gè)sql
    2）mysql 建立一個(gè)thread需要x 毫秒， 執(zhí)行一個(gè)sql的邏輯過(guò)程y毫秒，sql在代理內(nèi)的執(zhí)行時(shí)間z毫秒
    對(duì)于只是用mysql的的情況來(lái)說(shuō)：
    mysql需要針對(duì)m個(gè)連接建立m個(gè)線程，并且執(zhí)行n個(gè)sql，所以時(shí)間應(yīng)該是mx+yn毫秒
    但是對(duì)于代理來(lái)說(shuō)，mysql的連接是早就建立好了的長(zhǎng)連接，所以這塊的耗時(shí)忽略，他的時(shí)間是：
    mysql執(zhí)行n個(gè)sql的時(shí)間 和 n個(gè)sql在代理內(nèi)部業(yè)務(wù)邏輯的時(shí)間：ny+nz
    所以那個(gè)時(shí)間快慢就是取決于mx 和 nz的大小了。
    在并發(fā)量特別高的情況下，m會(huì)特別大，但是每個(gè)連接都執(zhí)行有限的sql，n特別小，這時(shí)候mx>nz
但是我的代理還是沒(méi)跑過(guò)mysql，從理論上看應(yīng)該是z特別大。

fender0107401

我在半生產(chǎn)環(huán)境用過(guò)，感覺(jué)挺好，但是我這邊對(duì)asio的壓力比較低。

lims_xlh

你是什么場(chǎng)景，我這邊是搞了一個(gè)mysql的代理，asio+coroutine的，效果不是太理想，在并發(fā)比較低的情況下比mysql快不了多少

fender0107401

回復(fù) 3# lims_xlh

我這邊是cs構(gòu)建的一個(gè)小系統(tǒng)，服務(wù)器端和客戶單用asio進(jìn)行各種通信，通信的頻率不高。
   

windoze

回復(fù) 3# lims_xlh

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

longshadian

boost.asio應(yīng)該性能因該不錯(cuò)吧，百度有個(gè)開(kāi)源庫(kù)sofa-pbrpc，內(nèi)部用asio實(shí)現(xiàn)。據(jù)說(shuō)在百度內(nèi)部廣泛使用。

lims_xlh

回復(fù) 5# windoze


    應(yīng)該是大并發(fā)的情況吧：因?yàn)榇�理有socket復(fù)用，但是mysql是一個(gè)連接一個(gè)線程，大并發(fā)的情況代理應(yīng)該是快的。

lims_xlh

回復(fù) 6# longshadian


   多謝，看一下他的實(shí)現(xiàn)

hellioncu

lims_xlh 發(fā)表于 2015-06-02 14:58
回復(fù) 5# windoze

我想他問(wèn)你應(yīng)該是認(rèn)為兩者不是一碼事，怎么比較

lims_xlh

回復(fù) 5# windoze

看了下asio代碼，我是一個(gè)線程一個(gè)io_service,每個(gè)線程應(yīng)該是一個(gè)op隊(duì)列，應(yīng)該不會(huì)有鎖的爭(zhēng)用問(wèn)題，不知道那個(gè)地方用的不對(duì)？