一、欧莱雅（中国）开系统

1、以前帮欧莱雅中国做店务通系统，程序中遇到过C++打开文件操作文件，不关闭，导致全国的零售终端越来越慢。——操作文件完成之后，要关闭

2、北京同仁堂的店务通系统，由于数据库的日志输出不当，服务器的日志越来越庞大并且塞满了硬盘，导致一些用户操作越来越慢——日志输出问题

3、大量的业务（进货、入库、会员、销售）所有的业务只操作一张表transactionlog表，最后做了分表操作——架构优化问题

 

二、法院审判软件

1、数据库打开不关闭，导致系统要每天都要手工重启服务，用户体验极差——数据库打开不关闭。

2、并发的问题，导致仅仅有5个人员在进行录入案子的操作的时候，就能把其他的案件信息自动带过来——程序优化。

 

三：名品打折网

1、特卖会活动，商品的排序规则算法问题（少量用户提现不出来），特卖会导致生产线上的专用服务器CPU耗尽到100%，电商网页打不开——排序算法程序优化。

2、在高并发测试过程中发现并发情况库存卖成负库存——程序优化。

3、生产环境生产订单程序很慢，优化后能在相同的时间内生成更多的订单——程序的优化。

 

四：华东电脑

1、Web服务死机，网页打不开,一开始一直找不到原因，测试和开发累的要吐血，最后定位Weblogic中间件参数错误的调成了开发模式（正确的应该是调成工作模式）——中间件配置问题。

2、验收测试过程中，1000用户并发情况下，响应时间超过了需求规格说明书中所要求——定位到图片过大的问题。

3、上海市学生学分系统，用户数上不去，登录时间过长，首页不是静态的，并且首页包含了大量的复杂的计算——程序问题

4、上海市中小学学生安全在线教育视频，在并发学习情况下，学生的学习时间为负数——数据库字段类型设置不当溢出了。

5、上海市学籍档案查询系统查询的响应时间达到33秒——增加索引优化查询。

6、登录响应时间长，在执行2000Vusers的学习视频测试场景中，登录步骤的平均响应时间达到12秒。通过数据库监控工具显示登录步骤存在慢的sql，此sql执行全表扫描，未建立索引。解决方案给sys_baseuser表增加索引index_3,增加索引以后，重新执行2000Vusers的学习视频测试场景中，登录的平均时间小于2秒。

7、系统资源存在瓶颈
从上述的结果来看，应用服务器和全文搜索服务器CPU资源使用接近100%，CPU存在瓶颈；应用服务器的内存存在换页现象，内存存在瓶颈。将应用服务器以及一台全文检索的服务器的资源配置由4C/8GB扩容至8c/16GB。服务器的内容扩充之后，相应的调整JVM虚拟内存的大小，最小值由1GB调整为4GB,最大值由4GB调整为12GB。

8、登录成功率低，登录成功率低于99%，报错信息为“请输入正确的图片验证码”，此问题是高并发的时候，打开的首页的时候未生成验证码，这个是属于第三方插件的bug。

9、应用服务器空指针错误，java.lang.NullPointerExcepton:null,此问题经过项目组排查，此问题是应用程序的判断逻辑问题。

 

 

五：厦门银行联合的P2P系统

1、在测试环境简单用jmeter测试了一下标的列表页和标的详情页，TPS飙升到370多，而且系统平稳。

2、用同样的测试场景测试了一下生产环境，网页变成白色打不开，后台的服务不停的报错。并且有大量的报错日志输出。

总结：当时国家在整治P2P，因此没有用户量，所以貌似生产环境没问题平时没有暴露出问题，其实是有问题了，就像一个人身上有慢性病一样，平时貌似没问题，但是在一些极端的情况下，比如这个病人在操场上跑步10圈或者干重活，这个病就有可能会爆发、人就有可能会挂掉。
对应这个P2P系统来说（系统的极端情况就是大并发量，大用户量的使用），系统的性能瓶颈立即就会爆发出来。