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

lims_xlh

回復(fù) 20# yulihua49


    你說這請求響應(yīng)快應(yīng)該是沒有問題，因為asio是處理完了io之后回調(diào)，所以會立刻響應(yīng)新的請求，
不知道你的一個完整請求的時長關(guān)注過沒有，是增加了還是比以前的減少了

yulihua49

lims_xlh 發(fā)表于 2015-06-02 19:34
回復(fù) 20# yulihua49

增加了。但增加的不多。

linux_c_py_php

starwing83 發(fā)表于 2015-06-02 16:33
回復(fù) 15# linux_c_py_php

  

starwing83

linux_c_py_php 發(fā)表于 2015-06-04 10:08

現(xiàn)在還在開發(fā)階段，之前弄好了buffer，現(xiàn)在還缺select實現(xiàn)和Lua綁定，做好了以后就來論壇正式發(fā)布，恩~

最近剛剛做了bench，本地洪水測試能到23W請求每秒，echo是11W，帶buffer的echo實現(xiàn)（支持即時發(fā)送和數(shù)據(jù)包回調(diào)）是9W。

wlmqgzm

我做的網(wǎng)絡(luò)服務(wù)器用ASIO做, 在雙核奔騰CPU上跑, 大約32萬QPS ECHO, 性能超強.

yulihua49

windoze 發(fā)表于 2015-06-02 13:57
回復(fù) 3# lims_xlh

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

mysql要有連接池。連接數(shù)為最佳連接數(shù)。請求的前端用戶數(shù)很多，大大超過數(shù)據(jù)庫連接數(shù)。
他們的請求在代理器里排隊。
有序的排隊，效率大大超過無序的競爭。尤其是有鎖的情況（像鐵路搶座），大家一起撞鎖，響應(yīng)會非常慢。一小波一小波的放進去搶，會好很多。
也就是所謂“適度并行”。

windoze

回復(fù) 26# yulihua49

但這樣依然不會比MySQL快�。孔疃嗑褪秦撦d能力比單個MySQL強而已。

yulihua49

windoze 發(fā)表于 2015-10-27 20:30
回復(fù) 26# yulihua49

但這樣依然不會比MySQL快�。孔疃嗑褪秦撦d能力比單個MySQL強而已。

我們不說單個的響應(yīng)時間，考察整體的交易吞吐量。
平均響應(yīng)時間也會減小。在超量的無序競爭中被卡住是很慘的，比排隊?wèi)K得多，你如果擠過公交估計有體會。
如果數(shù)據(jù)庫的最佳并行度是50，我一次放進去50.以后出來一個放進一個。性能肯定是最高的。
如果10000個人來搶，排隊的優(yōu)勢就非常高。
如果真的放10000個鏈接進入數(shù)據(jù)庫，而且競爭起來的話，估計數(shù)據(jù)庫就癱了。

單純的代理優(yōu)勢有限，如果代理換成中間業(yè)務(wù)服務(wù)器，以事務(wù)為單位與前端交互。業(yè)務(wù)服務(wù)器與后端數(shù)據(jù)庫，每取得一次鏈接完整的做一個事務(wù)是最高效的。
就是前端每次請求一個事務(wù)，事務(wù)做完服務(wù)器給一個總的應(yīng)答。
不要一個個SQL的請求，有時后端的連接池沒法處理。
比如：
cursor=prepare(...);    //返回游標(biāo)。但是后端的數(shù)據(jù)庫連接池釋放了。
fetch(cursor);             // 再次申請的數(shù)據(jù)庫連接，還是原來的那個？cursor有效嗎？
。。。。。

windoze

回復(fù) 28# yulihua49

我知道你的意思，但即便如此你也只能說負載能力強吞吐量高，就每一個請求的處理速度而言，代理肯定會更慢，想想就知道這是廢話，中間多經(jīng)過了一級當(dāng)然會更花時間。

我不是否定代理的好處，但如果你注重的是單個請求的處理時間，代理不是個好解決方案；如果你注重的是總體吞吐量負載能力并發(fā)數(shù)什么的另說。

wlmqgzm

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

我說一種情況, 就是mysql代理進行讀寫分離,

1) 讀服務(wù)器比較閑, 主服務(wù)器比較忙.
2) 讀數(shù)據(jù)可能在本地cache上有緩存,

這2種情況都比mysql快.