Open 499689317 opened 6 years ago
// 提交流程
机器人数量：
压测mysql:
压测redis:
测试内存是否会泄漏
压测websocket服务器：聊天服消息转发的承载量
vmstat 采样时间间隔/s 采样次数（查看整个物理机的状态，不是各个进程的）
top各个进程状态：查看某一用户开启的进程top -u 用户名
mysql并发io（所有玩家对各数据表做插入，更新操作）
redis并发：针对大对象的插入，更新操作
/server/robot/yourconfig.json { "server": "agentserver.node.aliyun.com:8080", "appid": "", "secret": "", "logdir": "/tmp/", "reconnectDelay": 10, "heartbeatInterval": 60, "reportInterval": 60, "error_log": [], "packages": [] } 通过下面命令启动agenthub nohup agenthub /server/robot/yourconfig.json &
192.168.2.41中mysql连接账号:doraemonkart密码:tEc*+HeTrU7U$AZa
192.168.2.70中mysql连接账号:dkart密码:dkart
192.168.2.22中mysql连接账号:doraemonkart密码:tEc*+HeTrU7U$AZa
几百到上千的并发量，服务器报error与timeout事件比较频繁 分析：因为内网路由只有一跳，与网络没有关系，应该是服务器性能有问题
去掉http服务器负载均衡
使用alinode与spotlight搭建完项目的压测环境
pm2启动进程时如果带参数，则每个参数前面都要带--，生产环境可能会选择pm2守护项目
test1服测试数据（cpu: 单核，内存: 1G） 同时在线：200, 并发数：200/sec (这种方式更贴近真实生产环境) 测试时长：超过12小时 qps: 203.33(200左右) gc时间占比：2.47%（健康状态--v8在回收内存时速度比较快） 系统占用cpu: 20%上下浮动 进程占用cpu: 15% 系统占用内存：接近50% 进程占用内存：接近20%（总内存占用100M左右，老生代内存占用40M左右，新生代内存10M左右） 磁盘占用：9% mysql执行sql语句：200/sec mysql占用cpu: 20% 磁盘IO: 350次/sec
同时在线：500，并发数：500/sec 测试时长：1个小时（记录时间：12:36-13.31） 测试时长：1个小时（记录时间：14:14-14:52） 测试时长：30分钟（记录时间：16：24-16：41） qps：494.1-509.7 gc时间占比：-- 系统占用cpu: 70-80% 进程占用cpu: 60%峰值达70% 系统占用内存：-- 进程占用内存：35% 磁盘占用：9% mysql执行sql语句：500/sec以上 mysql占用cpu: 45% 磁盘IO: 1200/sec 网络包传输：3000/sec
同时在线：800，并发数：800/sec 测试时长：30分钟（记录时间：16:00-16.22） qps：200-470之间 gc时间占比：-- 系统占用cpu: 80-90% 进程占用cpu: 60-70%峰值达83% 系统占用内存：-- 进程占用内存：25-30% 磁盘占用：9% mysql执行sql语句：600/sec上下 mysql占用cpu:60%上下（危险） mysql占用表空间：80% 磁盘IO: 1500/sec（写入） 网络包传输：4500/sec
同时在线：1000，并发数：1000/sec 测试时长：30分钟（15:25-15:55） qps：0 gc时间占比：28.52%（gc一次的时间非常长，非常频繁） 系统占用cpu: 90%以上 进程占用cpu: 20% 系统占用内存：99% 进程占用内存：60% 磁盘占用：9% mysql执行sql语句：(mysql已经跑不动了--计算机快崩溃了) 磁盘IO: 0 网络包传输：0/sec（接近）
注：报了大量的3010错误 崩溃原因主要还是在cpu与内存同时达到一个高峰值（猜测可能是硬件性能压到最大了）
500玩家分别每5秒1次请求 qps: 108.33稳定 cpu: 利用率20% mem：144.4M
800玩家分别每5秒1次请求 qps: 120.98不稳定 cpu：24% mem：186M
开始有问题（与玩家在线人数无关）
500玩家分别每5秒1次请求 qps: 90 cpu: 17% mem：138M
取消sql单核并没有增加qps，主要还是cpu与mem有所降低
800玩家分别每5秒1次请求 qps: cpu: mem：
项目测试连接数1000个，呵呵
nodejs ws模块裸测连接数在16000-17000之间
16000连接内存占用680.3M，cpu占用27%，libuv句柄数16000个，gc时间占比4.88%（此时进程非常脆弱）
sql语句内的*nux时间戳用法：unix_timestamp("2016-07-17 23:59:59")或unix_timestamp(1468771199)
ORDER BY 语句对查询结果排序，默认按照升序对记录进行排序
DESC LIMIT 0,2 取查询结果后第0-2条数据
redis的EXPIRE语句为给定的key设置生存时间
关闭redis: redis-cli -h 127.0.0.1 -p 6379 -a 3E=2DR?bReHem7n1 shutdown 启动redis: /etc/init.d/redis_6379 start
2018/02/07
// 提交流程
2018/02/24
机器人数量：
压测mysql:
压测redis:
测试内存是否会泄漏
压测websocket服务器：聊天服消息转发的承载量
vmstat 采样时间间隔/s 采样次数（查看整个物理机的状态，不是各个进程的）
top各个进程状态：查看某一用户开启的进程top -u 用户名
mysql并发io（所有玩家对各数据表做插入，更新操作）
redis并发：针对大对象的插入，更新操作
/server/robot/yourconfig.json { "server": "agentserver.node.aliyun.com:8080", "appid": "", "secret": "", "logdir": "/tmp/", "reconnectDelay": 10, "heartbeatInterval": 60, "reportInterval": 60, "error_log": [], "packages": [] } 通过下面命令启动agenthub nohup agenthub /server/robot/yourconfig.json &
2018/02/26
2018/02/27
2018/02/28
2018/03/01
192.168.2.41中mysql连接账号:doraemonkart密码:tEc*+HeTrU7U$AZa
192.168.2.70中mysql连接账号:dkart密码:dkart
192.168.2.22中mysql连接账号:doraemonkart密码:tEc*+HeTrU7U$AZa
几百到上千的并发量，服务器报error与timeout事件比较频繁 分析：因为内网路由只有一跳，与网络没有关系，应该是服务器性能有问题
去掉http服务器负载均衡
使用alinode与spotlight搭建完项目的压测环境
pm2启动进程时如果带参数，则每个参数前面都要带--，生产环境可能会选择pm2守护项目
2018/03/06
test1服测试数据（cpu: 单核，内存: 1G） 同时在线：200, 并发数：200/sec (这种方式更贴近真实生产环境) 测试时长：超过12小时 qps: 203.33(200左右) gc时间占比：2.47%（健康状态--v8在回收内存时速度比较快） 系统占用cpu: 20%上下浮动 进程占用cpu: 15% 系统占用内存：接近50% 进程占用内存：接近20%（总内存占用100M左右，老生代内存占用40M左右，新生代内存10M左右） 磁盘占用：9% mysql执行sql语句：200/sec mysql占用cpu: 20% 磁盘IO: 350次/sec
同时在线：500，并发数：500/sec 测试时长：1个小时（记录时间：12:36-13.31） 测试时长：1个小时（记录时间：14:14-14:52） 测试时长：30分钟（记录时间：16：24-16：41） qps：494.1-509.7 gc时间占比：-- 系统占用cpu: 70-80% 进程占用cpu: 60%峰值达70% 系统占用内存：-- 进程占用内存：35% 磁盘占用：9% mysql执行sql语句：500/sec以上 mysql占用cpu: 45% 磁盘IO: 1200/sec 网络包传输：3000/sec
同时在线：800，并发数：800/sec 测试时长：30分钟（记录时间：16:00-16.22） qps：200-470之间 gc时间占比：-- 系统占用cpu: 80-90% 进程占用cpu: 60-70%峰值达83% 系统占用内存：-- 进程占用内存：25-30% 磁盘占用：9% mysql执行sql语句：600/sec上下 mysql占用cpu:60%上下（危险） mysql占用表空间：80% 磁盘IO: 1500/sec（写入） 网络包传输：4500/sec
同时在线：1000，并发数：1000/sec 测试时长：30分钟（15:25-15:55） qps：0 gc时间占比：28.52%（gc一次的时间非常长，非常频繁） 系统占用cpu: 90%以上 进程占用cpu: 20% 系统占用内存：99% 进程占用内存：60% 磁盘占用：9% mysql执行sql语句：(mysql已经跑不动了--计算机快崩溃了) 磁盘IO: 0 网络包传输：0/sec（接近）
注：报了大量的3010错误 崩溃原因主要还是在cpu与内存同时达到一个高峰值（猜测可能是硬件性能压到最大了）
2018/03/08
2018/03/14
500玩家分别每5秒1次请求 qps: 108.33稳定 cpu: 利用率20% mem：144.4M
800玩家分别每5秒1次请求 qps: 120.98不稳定 cpu：24% mem：186M
500玩家分别每5秒1次请求 qps: 90 cpu: 17% mem：138M
800玩家分别每5秒1次请求 qps: cpu: mem：
2018/03/16
2018/03/19
项目测试连接数1000个，呵呵
nodejs ws模块裸测连接数在16000-17000之间
16000连接内存占用680.3M，cpu占用27%，libuv句柄数16000个，gc时间占比4.88%（此时进程非常脆弱）
2018/03/20
sql语句内的*nux时间戳用法：unix_timestamp("2016-07-17 23:59:59")或unix_timestamp(1468771199)
ORDER BY 语句对查询结果排序，默认按照升序对记录进行排序
DESC LIMIT 0,2 取查询结果后第0-2条数据
redis的EXPIRE语句为给定的key设置生存时间
2018/03/21
关闭redis: redis-cli -h 127.0.0.1 -p 6379 -a 3E=2DR?bReHem7n1 shutdown 启动redis: /etc/init.d/redis_6379 start
2018/03/22