发表于： 2018-03-18 23:36:16
1 629
日报格式：
今天完成的事情：
昨天师兄露了一手特殊注释，感觉效果很好玩，就去研究了一下特殊注释（注释代码呈蓝色）：
JAVA中，特殊注释有三种：TODO（未做事项）， FIXME（修复我），XXX（此处存疑，期待改进）
TODO: + 说明：
如果代码中有该标识，说明在标识处有功能代码待编写，待实现的功能在说明中会简略说明。
FIXME: + 说明：
如果代码中有该标识，说明标识处代码需要修正，甚至代码是错误的，不能工作，需要修复，如何修正会在说明中简略说明。
XXX: + 说明：
如果代码中有该标识，说明标识处代码虽然实现了功能，但是实现的方法有待商榷，希望将来能改进，要改进的地方会在说明中简略说明。
效果大概如下（可惜不能随意变色，残念）：
.png)
****************************************************************************这里是分割线***************************************************************************************
然后开始写压测报告：
1.测试内容：
本次测试是针对熟悉测试体系进行的压力测试。测试的项目为学员报名系统。
2.测试方法
本次采用apache的开源测试工具jmeter，采用http协议get方式发送读取数据请求。
四：测试环境
环境 | 机器型号 | 操作系统 | 硬件cpu | 硬件mem |
客户端 | windows | 四核 | 32G | |
服务端 | linux | 1核 | 2G |
五：系统部署：
Tomcat服务开两个端口，Nginx做负载均衡。单服务器，单客户端。
六网络访问:
通讯流程：
客户端------Nginx------Tomcat1或者2--------controller--------service接口
每种形式测试三次，测试结果如下：
.png)
七：结果分析
首先，在单纯测试json和测试缓存+json的时候，系统的反应速度几乎都在200--400ms左右
负载均衡状态下，系统响应速度都在1000ms开外。
而相对于对比组，负载均衡的效率普遍低于无负载均衡的对应组。
有一个奇怪的点是，redis测试JSP和测试json呈现出两个极端的反应数据。
******************************************这里是分割线***************************************************************
压测模板大概如下：
XXX压力测试报告
时间：
测试人员：xxx
目录
XXX压力测试报告
一 测试内容
二 测试方法
三 测试目标
四 测试环境
五 系统部署
5.1 物理部署
5.2 网络访问
六 性能测试结果与分析
6.1 jmeter集群压测（5进程-每个进行10线程）
6.2 jmeter集群压测（10进程-每个进行5线程）
6.3 jmeter集群压测（10进程-每个进行10线程）
七 结果汇总分析
****************************************************************************这里是分割线***************************************************************************************
然后登陆服务器查看服务器配置的时候，发现服务器被人攻击，好奇之下就搜了一下黑客访问的地址，以为是不会出现什么的，结果出现了一下界面：
.png)
然后去服务器看了一下后台密码，测试了几次，结果出现了三种不同的界面，然后我想了想，应该是负载均衡的效果：
.png)
然后还有一个提示你要去配置user文件的提示界面，不知道是不是cookie原因，进入过一次之后就再没看到过那个页面。
.png)
但是为什么会出现两种结果，我觉得是因为负载均衡，因为我只在其中一个服务器上配置过管理员密码。
然后，我更换到我设置的tomcat端口，一次命中，直接登录后台。http://blog.fens.me/black-ip-list/
然后我看到了这个：
.png)
点击浏览，可以开始上传文件：
.png)
然后我无意中往下翻了翻tomcat的页面，在最底下发现：
.png)
也就是服务器的一些基本信息都在这。
然后我删除了自己在服务器的管理员账户，重启了Tomcat，进入到阿里云控制台的时候，又看到这个：
.png)
我点进去Web应用防火墙：
然后看到了阿里云的惊喜,大家感受一下：
.png)
单
****************************************关于系统压测一些计算公式与概念******************************************
1、平均并发用户数
C = nL/T
其中
C：平均的并发用户数；
n：平均每天访问用户数（login session的数量）；
L：一天内用户从登录到退出的平均时间（login session的平均长度）；
T：考察的时间段长度（一天内多长时间有用户使用系统）；
2、并发用户数峰值：
C'≈C+3*根号C
其中
C：公式1中的平均并发用户数；
3、请求数计算公式：
R = T / TS
其中
R：每个虚拟用户发出的请求数；
T：性能测试所用的时间；
TS：思考时间；
4、吞吐量计算公式
F=VU * R / T
其中
F：吞吐量；
VU：虚拟用户个数；
R：每个虚拟用户发出的请求数；
T：性能测试所用的时间；
5、TPS计算公式
TPS = 并发数/平均响应时间
在现实世界里，登陆的用户是按照以下的方式运作的：
1、沉睡状态 -- 在非工作时间不登陆；
2、片刻状态（上升） -- 开始工作的时候，人们开始登录系统；在线的数量不断增加；
3、稳定期 -- 在线的用户数保持稳定；
4、片刻状态（回落） -- 工作时间结束；人们退出系统；在线人数减少；
这四个状态周而复始。
我们要更精确预估高峰期并发用户数，应该遵循下面的步骤：
1、根据经验来估计稳定期的时间段；
2、估计在稳定期的登录用户数；
3、根据公式计算平均并发用户数；
4、运用公式计算高峰并发用户数；
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达 到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下 降。
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。
单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
***********************************************这里是分割线**********************************************************
明天计划的事情：开始任务七的邮箱验证。
遇到的问题：
1.邮箱验证如何不备案就可以实现功能。
收获：
1.以完成任务的心态去学习，进度反而是最慢的。
进度：
任务开始时间：2018年02月08日
预计demo时间：2018年0218日
禅道地址：http://task.ptteng.com/zentao/project-task-490.html
返回列表
评论