项目终于结束了，不过感觉像是稀里糊涂的完成了。一些简单的接口完成了目标，也有两三个接口没有完成进行测试或是没有达到目标。
其中最关键的一个接口，未优化前平均响应时间是四五十秒，TPS最查差时能达到0.9左右。优化后，经过多轮调试，最好的结果是平均响应时间达到0.9秒左右，
TPS达到30/sec。优化的手段是，开发将一些创建大对象的程序放置在别处进行，不在主程序中执行。然后一些创建对象的实例，再进行赋值的操作，一步到位，创建了
对象的同时也进行赋值，减少一个操作。这是代码方面的一些优化，效果立竿见影，压测后，比对了每个请求所产生的日志文件，从384K左右，降到了244K，一次并发，七八
千个请求，总之前产生2G多的文件，降到1G多，大大提高了存储的空间。
内存方面的优化。刚开始时没有关注JVM内存这块，开发也是设置得比较低，年轻代设置1G，其他配置也是弄得挺多，反正不知设置其意义是啥。最初执行，一旦有负载，
内存一下子吃紧，占用率达到80多，且都是应用程序的执行引起的。检查了jvm的配置后，设置了年轻代 2G，4G，5G，6G 这几个值，同时调大了最小堆和最大堆的配置，然后一一进行调试，同时配合开发的代码调试，FGC从最初的三四次每秒到后来的0次每秒，YGC也从最初的10次左右，降到平均1秒1次。
在查看jvm的情况时，我经常使用 jstat -gcutil
我居然使用YGC/YGCT，或者FGC/FGCT 来求出他们的平均次数。后来在某次调试中，想了下，2000 代表的是毫秒，10代表显示10条记录，也就是每2秒打印一次记录，那FGC
或者YGC的时间间隔是2s，而不是FGCT，FGCT是从启动程序到回收这段的总共花的时间。。。真实被自己蠢哭了，哎，自身学艺不精。其实使用YGC或者FGC，每天记录的后一条
减去前一条，然后除以时间间隔，就知道每秒回收几次，不然将2000改为1000,这样直接计算的结果的就是每秒的回收结果，更省时。
这一次的性能测试感觉自己真的帮不上什么忙，就只是简单的执行脚本，看看监控指标，指标还不那么熟悉，囧。除了这些还不够，这次还学到一个知识点，压缩文件，当文件数量
非常多时，这个操作是很占用CPU资源，所以不管是放在本地内存还是Redis，所以开发决定不压缩文件写入磁盘，这样以空间换时间，但为了有更多的空间存储文件，在生产环境
中提前准备了500G左右的NAS，因为日志文件只需保存七天，七天后就销毁。为了提高性能，不得不做出一些平衡。
这次的优化只要针对代码层面的优化，然后将Redis缓存变为二级缓存（本地缓存+Redis缓存），确实起到了一定的效果，但距目标100QPS还有很长的距离。数据库方面没有进行
优化，这一块组内没有多少人懂。我隐约觉得数据库这块优化完，还能将目标再提升一个级别，毕竟数据库的设计，比如索引，SQL的用法，连接池的设置等这些东西，能找出一些
问题，优化一下的话，至少比当前的效果好。可惜自身实力不足，不足以支撑这样的性能测试。
另外一个比较遗憾的是，没有Java基础，即使把堆栈信息打印出来了，但因看不懂，也无法指出原因所在。有一回，开发给我指出他的优化，我在旁边频频点头，其实看得懵逼呀，WC，好丢人。打铁还要自身硬才行。