gatewayworker做的登錄服, 1個(gè)gate,5個(gè)worker;另有一客戶端,開了10個(gè)worker,每個(gè)worker啟動(dòng)時(shí)向登錄服發(fā)起1000個(gè)tcp連接,發(fā)現(xiàn)建立連接時(shí)出現(xiàn)unable to connect to tcp://192.168.20.166:18310 (Unknown error)
?
我的測(cè)試模型有什么問題嗎?出現(xiàn)這個(gè)問題,我感覺應(yīng)該是gate在處理客戶端連接時(shí)響應(yīng)不過來造成的,有什么好的測(cè)試模型嗎?目前的測(cè)試,這個(gè)登錄服只作了賬號(hào)創(chuàng)建,然后就沒有了!
?
賬號(hào)創(chuàng)建,確實(shí)是寫數(shù)據(jù)庫的,因?yàn)橛脩鬷d是自增,所以依賴于這個(gè)創(chuàng)建結(jié)果,難道這個(gè)就是我的瓶頸!?
假如這個(gè)創(chuàng)建過程我省略了,難道就能應(yīng)付這個(gè)壓力測(cè)試嗎,我感覺還是挺擔(dān)心的!
?
1、首先workerman是高性能異步非阻塞IO的socket框架,所以毋庸置疑其高性能,對(duì)付高并發(fā)連接不在話下。而gatewayworker 基于 workerman開發(fā)的,那gatewayworker自然也繼承了這一本領(lǐng)。
2、測(cè)試模型看上去沒問題呢,10個(gè)worker也不過1w個(gè)連接而已。
3、高并發(fā)連接,尤其是超過1000個(gè)連接的應(yīng)用,需要安裝event擴(kuò)展,并優(yōu)化內(nèi)核:
http://doc.workerman.net/appendices/kernel-optimization.html
您好,您提供的連接是關(guān)于linux內(nèi)核優(yōu)化的,但是我按類似的方法在mac下找,一直沒找到對(duì)應(yīng)的配置文件,可有在mac下進(jìn)行內(nèi)核優(yōu)化的文章呢,感謝!
MAC下不了解,沒有 /etc/sysctl.conf 這個(gè)文件嗎? 全局再搜索下sysctl.conf試試,只曉得MAC內(nèi)核和LINUX內(nèi)核有很多相似之處。
@614:這個(gè)文件確實(shí)沒有的,不過網(wǎng)上有人說新建一個(gè),我試了下,確實(shí)能生效。然后我又重新測(cè)試了下,發(fā)現(xiàn)遇到2類錯(cuò)誤:
不知道是什么原因呢?
相關(guān)配置參數(shù)我列下:
[zcm@GatewayWorker 9]$ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1048576
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 709
virtual memory (kbytes, -v) unlimited
[zcm@GatewayWorker 10]$sysctl -a | grep files
kern.maxfiles: 1048600
kern.maxfilesperproc: 1048576
kern.num_files: 2717
修改了客戶端,在connect到server進(jìn)入onclose時(shí),1秒后重新調(diào)用建立連接接口,發(fā)現(xiàn)變成死循環(huán)了,難道10個(gè)worker,和1000個(gè)連接,一臺(tái)電腦上都無法承受嗎?
1、每個(gè)進(jìn)程你不是模擬的1000個(gè)鏈接嗎? 為什么會(huì)是死循環(huán)不停的建立連接?應(yīng)該有個(gè)出口才對(duì)的
2、一臺(tái)機(jī)器能承受多少連接數(shù),是受限于內(nèi)存和內(nèi)核的參數(shù)設(shè)置的
3、Warning: socket_set_option(): unable to set socket option 這個(gè)報(bào)錯(cuò)對(duì)應(yīng)源碼我看了下,底層的不應(yīng)該啊,是最新代碼嗎?
gatewayworker今年前幾個(gè)月下的,Worker版本3.5.14,死循環(huán)是因?yàn)槲业目蛻舳巳ミB接服務(wù)器,$connection->onClose里,我用了Timer::add(1, reconnect, [], false), 大概是這個(gè)樣子!
1、對(duì)于那個(gè)warning,我建議你檢查下你PHP版本、或執(zhí)行用戶的權(quán)限、或sockets擴(kuò)展問題等【sockets擴(kuò)展隨官方PHP默認(rèn)發(fā)布】
2、按你說的 onClose 這里只是 reconnect 邏輯,不沖突呢,弄個(gè)全局計(jì)數(shù)器,直接在onConnect 里發(fā)起指定計(jì)數(shù)器的長(zhǎng)連接,其實(shí)最簡(jiǎn)單了。
php版本應(yīng)該沒什么問題,sockets擴(kuò)展也是隨php安裝的,沒有單獨(dú)安裝過!
[zcm@GatewayWorker 2]$php -v
PHP 7.2.11 (cli) (built: Oct 11 2018 16:23:06) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Xdebug v2.6.0, Copyright (c) 2002-2018, by Derick Rethans
with Zend OPcache v7.2.11, Copyright (c) 1999-2018, by Zend Technologies
執(zhí)行用戶的權(quán)限應(yīng)該也沒問題,因?yàn)榭蛻舳藬?shù)量少一點(diǎn)就不會(huì)出錯(cuò),多了才出上面的錯(cuò)誤,所以我想主要問題可能還是在內(nèi)核參數(shù)上面吧,因?yàn)橛胢ac作服務(wù)器,他上面的內(nèi)核參數(shù)不知道有沒有區(qū)別,我把服務(wù)器部署到linux上試了下,沒有任何錯(cuò)誤,所以這壓力還是可以承受的,只不過有可能是我測(cè)試模型的原因,10個(gè)worker進(jìn)程,但每個(gè)進(jìn)程中發(fā)起客戶端連接是串行的,所以全部跑下來花了一二分鐘,代碼里有少量的打印信息!
你說的第2個(gè)問題是怕我有邏輯上的問題,導(dǎo)致死循環(huán)連接是吧,這個(gè)我可以修改下,問題不大!
@614:將服務(wù)器部署到linux(普通筆記本硬盤)上,客戶端在mac上(SSD),服務(wù)器的gate開了3個(gè)進(jìn)程,worker開了10個(gè)進(jìn)程,客戶端是開了10個(gè)worker,每個(gè)worker發(fā)起1000個(gè)客戶端連接,全程跑下來用了近5分鐘,每個(gè)客戶端要處理的事情是創(chuàng)建賬號(hào)(向mysql插入一條記錄), 并有4-5條報(bào)文交互!這樣的性能感覺太差了點(diǎn),用的是php7.2,不知還有多少優(yōu)化的空間!
QPS也是衡量性能高低的一個(gè)指標(biāo),性能高低也是受制于方方面面方面因素,從語言本身到腳本的優(yōu)化、硬件、內(nèi)存、帶寬以及分布式部署等等都有影響。另外這幾個(gè)鏈接你再參考下:
http://doc.workerman.net/315230
https://wenda.workerman.net/question/3285
http://doc.workerman.net/appendices/kernel-optimization.html
@614:客戶端登錄,服務(wù)端處理時(shí)會(huì)在mysql中插入一條記錄創(chuàng)建新賬號(hào)!是服務(wù)端的worker做的!