node-php-server性能测试

guoyilongedu

于 2021-12-04 17:15:14 发布

阅读量3.1k

点赞数

分类专栏： nodejs Linux服务器编程游戏开发文章标签： php 服务器 tcp/ip

本文链接：https://blog.csdn.net/guoyilongedu/article/details/121717484

版权

Linux服务器编程同时被 3 个专栏收录

14 篇文章 1 订阅

订阅专栏

游戏开发

7 篇文章 1 订阅

订阅专栏

nodejs

4 篇文章 0 订阅

订阅专栏

node-php-server 介绍如下

node-php-server 游戏服务器框架_guoyilongedu的专栏-CSDN博客

代码地址

https://github.com/guoyilong/node-php-server

１.并发的连接数测试

测试之前的连接数

[vagrant@localhost ~]$ netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
TIME_WAIT 1
ESTABLISHED 2
LISTEN 26

开启8个客户端　每个客户端开启1000个连接　测试代码　用go 每个连接　开启一个协程　接收服务器的回包

[vagrant@localhost ~]$ netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
ESTABLISHED 8003
LISTEN 26

8000个连接　妥妥的，没问题，游戏指令的操作，广播都不受影响。

send msg json = {"user_id":121,"cmd":101,"msg":"broadcast"}
 ====> 111 2b
===> send byte   51
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 79
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 2B
==1111=======> hexs = 7B
==1111=======> hexs = 22
==1111=======> hexs = 75
==1111=======> hexs = 73
data =  from client from php  msg = broadcast
 cost time msec = 662

就是广播有点耗时，8000个连接的广播，却实有点耗时，正常情况下，也不用推送那么多玩家，这也是极限情况，当然如果要做万人同屏的效果，肯定要用分布式推送服务器，多台服务器同时推送，减少压力。

广播测试

php层向node-php-server 发送消息，node-php-server再广播消息给所有客户端，3000个连接，广播耗时400ms左右，如果是1000连接，小于80ms 左右就可以搞定，单服1000人同时在线，已经很不错了，所以我觉得广播推送的性能还是OK的.

如下图是3000连接耗时的统计358ms

data =  from client from php  msg = broadcast
 cost time msec = 358
data = result is {"msg":"broadcast","msg_index":"9","sleep_ms":"0","field_num":"1"} pid 6261
 cost time msec = 2

如下是4000连接耗时的统计　第一次421ms 第二次340ms

send msg json = {"user_id":121,"cmd":101,"msg":"broadcast"}
 ====> 111 2b
===> send byte   51
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 79
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 2B
==1111=======> hexs = 7B
==1111=======> hexs = 22
==1111=======> hexs = 75
==1111=======> hexs = 73
data =  from client from php  msg = broadcast
 cost time msec = 421
data = result is {"msg":"broadcast","msg_index":"12","sleep_ms":"0","field_num":"1"} pid 6261
 cost time msec = 135
broadcast
send msg json = {"user_id":121,"cmd":101,"msg":"broadcast"}
 ====> 111 2b
===> send byte   51
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 79
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 2B
==1111=======> hexs = 7B
==1111=======> hexs = 22
==1111=======> hexs = 75
==1111=======> hexs = 73
data =  from client from php  msg = broadcast
 cost time msec = 340

测试单条命令耗时过久对其他命令有没有影响

测试方法:如果发送特殊命令，在php层阻塞10s,同一个客户端再发其他命令，看能不能及时得到服务器的回包。

   if ($the_msg == "gyl") {
        $sleep_ms = 1000 * 10;
    }
    else if ($the_msg == "broadcast") {
        broadCastMsg(121, $the_msg);
		$sleep_ms = 0;
    }

发送gyl 时　就阻塞10s

gyl
send msg json = {"user_id":121,"cmd":101,"msg":"gyl"}
 ====> 111 25
===> send byte   45
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 79
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 25
==1111=======> hexs = 7B
==1111=======> hexs = 22
==1111=======> hexs = 75
==1111=======> hexs = 73
sssss
send msg json = {"user_id":121,"cmd":101,"msg":"sssss"}
 ====> 111 27
===> send byte   47
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 79
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 00
==1111=======> hexs = 27
==1111=======> hexs = 7B
==1111=======> hexs = 22
==1111=======> hexs = 75
==1111=======> hexs = 73
data = result is {"msg":"sssss","msg_index":"15","sleep_ms":"150","field_num":"1"} pid 6261
 cost time msec = 168
data = result is {"msg":"gyl","msg_index":"14","sleep_ms":"10000","field_num":"1"} pid 6261
 cost time msec = 1381

可以看到发送gyl 时，客户端没有立即收到回包，在等服务器返回, 等待的过程中，再发一次其他命令，立马就收到回包，而gyl这条命令的回包则等了好几秒才回。

说明极个别的长耗时命令，对其他的命令没有任何影响，这对游戏的体验就比较好，毕竟谁也没法保证每条游戏操作的指令都是快速处理的，有长耗时的不能对其他的操作指令造成影响。显然这里是合格的，能达到要求。

如果长耗时的命令比较多怎么办，除了想办法优化业务逻辑之外，还可扩充服务器的吞吐量，可以修改node-php-server 的服务器配置，就可以达到

	"php_connect_num":10,
	"worker_num":36

如上　36 * 10 = 360 node-php-server 同一时刻可以并行处理360 条网络命令，记住是并行，不是并发，360条之外的其他命令，得排队进行处理，玩家的操作指令是随机的，毕竟都需要手点的。很难同一时刻涌进这么多网络命令。扩容的话，增加进程数，比较耗内存，建议修改php连接数，吞吐量，成倍增加，当然php-fpm 这边也得扩容。

备注: 测试代码　github 上有　go 代码后面上传(自己也是现学现卖)