今天完成的事情：初步了解jmeter 重装服务器系统

服务器被黑了，之前任务的表变成了WARING 然后解决方法就是删除表 ，重新建表 

自己傻了吧唧的重装了系统 

重装系统好麻烦，以后记得要镜像

性能优化基础

为什么做性能优化

为了给客户更好的体验，就是让打开网页的速度更快，因为人对200MS以上的时延有反应，所以应将程序的反应时间缩短至200MS以内

定位响应时间

用户个人信息这种请求，应该在50MS左右

List的数据，差不多在100MS左右

所以做性能优化的时候一定要很清楚的知道请求的反应时间

网络请求的时间损耗分为三部分

第一部分前端的响应，一般包括解析和渲染，这部分的性能跟前端的代码，前端硬件有关系
第二部分就是网络延迟，这部分的代码正常来讲是在8~16MS左右，Http请求就是差不多这个性能
第三部分就是服务器端的响应，网站慢，一般而言，也就是主要在这里，要做性能优化的地方，基本上也是看这里。

Nginx和Tomcat

后端需要解决的就是服务器端的响应时间，这里就用到了之前的Nginx和tomcat

我的理解是tomcat负责承载代码，Nginx负责管理tomcat

如果响应时间过长，可以查看服务器日志信息

Controller和Service

Tomcat里运行的是代码，运行的快慢主要跟Controller还有Service有关

Controller跟Service的关系也是管理的关系，Controller 负责管理Service

所以Tomcat响应的时间可以分为：
1.Controller的处理时间
2.Service的调用时间
3.返回结果的处理时间

Controller统计时间
写一个AOP的Util。并不会在Controller里手写StartAt和EndAt
如果超过了XXMS，记录日志，入参，时间。
如果不超过XXMS，不记录。

缓存

个人理解就跟我们平时看视频一样，总会产生一个临时文件，如果我们看到一半没有看，下次在看的时候会从上次停止的地方继续播放，从缓存中调用数据比直接从DB中调用数据要快

系统吞度量要素：

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。

单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

QPS（TPS）：每秒钟request/事务 数量

并发数： 系统同时处理的request/事务数

响应时间：  一般取平均响应时间

QPS（TPS）= 并发数/平均响应时间

一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

决定系统响应时间要素

做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期

系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间；

关键路径是有CPU运算、IO、外部系统响应等等组成。

明天计划的事情：继续任务六