今天完成的事情：

1. 测试 jmeter 脚本

脚本中加入了登录操作，但是服务器还是压不挂，主要是带宽太小了，请求没能全部打过去。

一开始没发现是带宽不够，实在是太慢了才想到去看一眼服务器的管理页面发现带宽都满了，毕竟是 1M 的小水管，真的经不起这种冲击。

群里问了一下师兄，让直接去服务器上跑 jmeter，但是还是遇到了 jmeter 自己的线程无法关闭的问题，测试线程少一点的时候是没有问题的，改成 50 个线程还是会卡死。

我手动调整了 jmeter 的内存，效果不明显。推测 jmeter 的内存和线程数存在一个匹配，超过了一定的数量就会出问题，明天这个问题接着排查。

生成了 tps 图如下，看着有点乱信息量也挺低的，所有的请求都成功了，开的是 50 个线程，峰值每秒处理 40 个事务。

2. 在服务器上安装了 memcache

收获：

1. 什么是压测

压力测试是通过不断向被测系统施加“压力”，测试系统在压力情况下的性能表现，考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在，也就是我们可以模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。

有两种错误类型是:内存泄漏，并发与同步。

有效的压力测试系统将应用以下这些关键条件:重复，并发，量级，随机变化。

2. 什么是 tps

TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每个呼叫平均TPS） TPS是软件测试结果的测量单位。

一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

 一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。

3. 压测时常见的指标简介

QPS：Query Per Second，每秒处理的请求个数 

TPS：Transactions Per Second，每秒处理的事务数，TPS <= QPS 

RT： Response Time，响应时间，等价于Latency RT分平均延时，Pct延时（Percentile分位数）。平均值不能反映服务真实响应延时，实际压测中一般参考Pct90，Pct99等指标 

CPU使用率：出于节点宕机后负载均衡的考虑，一般 CPU使用率 < 75% 比较合适 内存使用率：内存占用情况，一般观察内存是否有尖刺或泄露 Load指标：

CPU的负载，不是指CPU的使用率，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，表示CPU的负载情况，一般情况下 Load < CPU的核数*2

缓存命中率：多少流量能命中缓存层（redis、memcached等） 

数据库耗时：数据库就是业务的生命，很多时候业务崩掉是因为数据库挂了 

网络带宽：带宽是否瓶颈 接口响应错误率 or 错误日志量

QPS和TPS的区别： 

QPS一般是指一台服务器每秒能够响应的查询次数，或者抽象理解成每秒能应对多少网络流量 TPS是指一个完整事务，一个事务可能包含一系列的请求过程。

访问一个网页，这是一个TPS，但是访问一个网页可能会对多个服务器发起多次请求，包括文本、js、图片等，这些请求会当做多次QPS计算在内，因为它们都是流量

遇到的问题：

1. jmeter 线程无法关闭，测完之后部分线程停不下来（我设置了循环次数，不会是设置了无限循环的问题，也没有开启时间限制）

猜测有两种可能：

a，部分请求丢失

b，jmeter 一定的内存下不能开启太多线程

2. 关于 memcache 的使用

一开始以为时应用服务器加装个软件就行了，仔细看了一下发现要和项目做整合，好吧，明天整。

明天的计划：

1. 继续解决 jmeter 的问题

2. 整合 springmvc 与 memcache