这段时间忙着帮北京某城商行做移动端性能测试，因移动端IPD、手机等都是无线设备，而且该客户是面临全国各地用户提供移动端APP支持，为了更真实的模拟测试，我跟该项目的项目经理沟通直接在厦门本地通过无线网借用LR工具模拟并发压力测试。很感谢移动架构组的技术专家肖工的帮忙，让我顺利的在本地搭建了模拟机，并跟该项目经理要了生产环境的APK工程包部署后，并根据项目组提供的业务操作手册学习业务知识，后使用LR开发脚本进行压力测试。
因地域距离关系，而且是直接在生产环境压力测试，生产环境在北京，压力测试机器在厦门，通过无线压测，所以测试过程对服务器资源使用监控成为一大问题，只能在每次压力测试时通过微信交流，在碰到响应时间等相对比较长或者TPS不稳定时，让项目经理协助监控，拍照截图我分析，还好自己这十几年到出差支持项目做性能故障分析优化，对各类问题通过LR前端能猜测出后端是数据库问题还是应用问题，虽然没办法做到真正的知微见著，但是还能通过现象了解本质问题，并提供优化建议，这主要是因为工作走心，也有事物去总结积累的效果。
刚开始压测时因是默认部署后默认配置等问题导致响应时间偏高，TPS低，经项目经理反馈应用CPU 都82%以上如下图：
测试了四五支交易发现都有共性问题，响应时间都是六秒以上，手机端响应时间一般是258原则，超过5秒使用者都会烦躁直接关闭，一般建议都是3秒以下，因此指标没办法满足。
猜测应该是应用服务器配置不合理导致的，因为登录退出、页面连接等也有共性问题，大概测算下后，给项目经理提供相关的配置优化意见后，竟然真的解决了，主要是tomcat相对好优化，然后通过再压测响应时间都在1秒以下。
一般银行的APP移动端的应用逻辑也不会太复杂，代码写法问题相对比较少，而且是胖客户端的，数据传输虽单机业务数据量少，但是并发大，在测试过程中如果发现性能问题，一般是网络带宽问题或者后端处理逻辑问题。假如测试过程中如果大部分交易有问题一般是软硬环境配置不合理居多，如果有时偶尔一两支查询交易响应比较慢，一般是SQL写法问题引起的，建议先看SQL语法执行路径如何，是走全表扫描，全索引扫描？是否因多表关联等写法导致的，这时在根据实际业务情况进行优化。--当然问题原因很多还是多监控诊断分析，性能监控数据说话才更真实和权威。
