使用资源监视器监控服务器性能是不错的方法。今天从几个方面来讲：

实战来源：环宇租赁   服务器：阿里云ECS 8核32G  初始 10M带宽，后升级为200M

资源监视器大概分五个标签，概述，CPU，内存，磁盘，网络

环宇的问题主要在于学生在开学后，批量的租赁空调和交费（对接新开普的接口），2021年9月份的时候开增加了山东两个学校的网签功能。2021年9月11日当天，学生租赁数量+交费数量大概在  2000多条。 9月12日的时候数量更是猛增到   条。

服务器方面优化做的几点工作

1、发现大量学生因为访问变慢，就会提交维修，这时需要上传图片，图片婷婷技术做程序时，没有压缩，直接就传到服务器端。这还没有结束，学员发现问题没有解决，就会查看当前维修状态，从服务器端下载此图片。这增加了很大的带宽和读盘消耗。

解决应策：把学生上传的图片，打包下载下来，修改成小图片上传。  第二让婷婷干脆把上传图片的功能取消，临时学生只能以文字方式提交。

2、把当前程序中所有图片的质量都作了压缩，尽量减少带宽开支。

3、提高硬件配置，把原来的带宽从10M提高到30M，这样坚持了11号夜里，后来发现这个方法并不好。干脆在第二天，直接升到200M，升级带宽，确实解决了用户速度问题。只是这时访问数据库交互时会卡，网速没得说了。

4、减少磁盘访问，阿里云主机有一个不好的设置，就是云盾会不定时的访问正常的主机下的资源，这个是在资源显示器下的磁盘活动一栏，果断的暂停了网签程序，发现云盾不再访问了。这一操作减少磁盘的读数量，节省了资源。

5、学生或者说用户吧，有个不好的习惯，如果操作不顺畅，喜欢刷新，这就造成了多次的TCP访问，同时增加了数据库的读写操作。再加上之前的维修功能，总结为：越慢越慢！ 

6、关于资源监视器中网络TCP的网络延时，网络延时有个标准如下（感觉像网络游戏的角度说的）：

1~30ms：极快，几乎察觉不出有延迟，玩任何游戏速度都特别顺畅
31~50ms：良好，可以正常游戏，没有明显的延迟情况
51~100ms：普通，对抗类游戏在一定水平以上能感觉出延迟，偶尔感觉到停顿
100ms~200ms：较差，无法正常游玩对抗类游戏，有明显卡顿，偶尔出现丢包和掉线现象
200ms~500ms：很差，访问网页有明显的延迟和卡顿，经常出现丢包或无法访问
>500ms：极差，难以接受的延迟和丢包，甚至无法访问网页
>1000ms：基本无法访问

环宇的网络延时在高峰时期大概平均在 400 左右，应该说还是体验不太好，有视频测试过访问页面大概在4-5秒进来，第一天带宽在30M的时候应该根本不行，第二天加到200M时，一直就没有卡死过。也就是说用户只是多等了一小会，然后能操作完成。

7、关于多并发的几个思考

多并发服务器配置在8核32G，应该说不差了。环宇实际同时在线人数，可能在300人（这个是从TCP连接估算）。服务器这次从数据库读写入手，改动了缓存，不过收效不明显。 后面可以使用高效的云MYSQL数据库。

腾讯的支付回调

腾讯的支付回调不成功警告，这是微信开发支付功能以来，第一次遇到。最多的时候出现过5分钟内将近200次回调不成功。回调不成功的初期，微信有一个频率规则，大概是 3s/3s/3min/3min/3h/3h/3h....这种规则，即开始重复执行的时间短，这加剧了服务器的负担，即当支付不成功时，马上又会执行这个回调，后面再开发项目，如果遇到高并发，应该是至少1个小时之后，再处理回调的事情，可能会更好。