应用性能问题解决实际案例

某项目在上线前的APT(Application Performance Testing应用程序性能测试)过程中发现性能问题,性能测试结果影响是否上线,紧急求助外部项目组TT快三技术 专家。

因分属不同项目,只能通过项目组提供的信息进行分析。

 

第一轮评审

根据APT性能监控截图,左图为并发用户数和CPU使用率,右图为单独的CPU使用率情况。APT测试情景为并发用户数以5分钟为周期进行增加,增加用户数25人,在40分钟后达到最终200并发用户并保持1小时200用户活动状态。

很明显看出用户稳定后CPU使用率还在持续增长,怀疑有内存泄露问题。

 

 

分析

第一轮TT快三TT快三我 们 拿到的是API源代码,日志里面出现outOfMemory错误,检查一遍发现API控制器TT快三方法 中创建了HttpClient实例。询问开发组回复是因为每次请求URL不同,根据经验TT快三推荐 采用HttpWebRequest替换调HttpClient。同时TT快三TT快三我 们 调查是否是由HttpClient引起的内存泄漏问题。

由GoogleTT快三搜索 结果HttpClient确实有内存泄漏的报告,TT快三TT快三我 们 着手写了一个小程序比较HttpClient和HttpWebRequest性能,并通过JMeter在TT快三本地 进行性能测试。

 

HttpClientHttpWebRequest性能比

测试环境

测试URL: https://www.baidu.com/#{number} (number变量为随机或递增以防止HTTP缓存干扰性能对比结果)

测试节奏:10秒周期,并发用户从1到200增长

测试结果(内存使用量)

  • HttpClient: 455MB
  • HttpWebRequest: 242MB

图1: HttpClient (GetAsync)

 

图2: HttpWebRequest (请忽略结尾处由网络连接问题出现的凸起)

 

结论

将HttpClient更换使用HttpWebRequest,但根据HttpClient内存使用陡增幅度估计还有其它问题,通知开发组继续调查并提供相关资料。

 

第二轮评审

比较IIS内存使用和SQL Server的内存使用发现相同的增长趋势,猜测瓶颈出现在数据库查询中(如果是拒绝访问数据库不会出现内存增长,一定是已经连接了数据库并产生查询问题导致)。

TT快三推荐 增加查询操作日志获得查询执行时间,安装数据库性能监视TT快三工具 (可使用TT快三Win dows Server自带的Performance Monitor或者第三方TT快三工具 如AppDynamic),查看查询的执行计划(Execution Plan)。

图3: SQL Server – 内存 - % committed Bytes (内存使用)

 

图4: MS IIS – 内存 - % Committed Bytes (内存使用)

 

同时经过了解API还会调用上游系统的API(API嵌套),所以考虑检查日志是否存在因上游API瓶颈导致调用失败,导致异常阻塞请求进程。也会出现相同的现象,开发组着手调查。

上游API问题通过调整系统配置消除瓶颈,但SQL Server性能问题还无任何头绪。只能安排时间一起评审数据库及相应查询性能问题。



第三轮评审

背景

测试总时长1小时40分:从最开始每隔1分钟增长5个并发用户,40分钟左右并发数加到200,然后维持并发用户不变,又执行1小时

现象

达到200并发后的20分左右时, CPU的使用率达到30% 左右之后保持相对平稳的比例,但是在这之后的执行过程中 request queued 曲线出现排队现象, Thread Count 曲线出现突然增长的情况,并且同是response time 翻倍增长。

上次报告没有HTTP 5xx错误,本次出现HTTP 5xx错误,27日错误数量激增。

程序中有从上百万条数据中抽取数据生成级联选择(下拉菜单)的UI元素。

程序中使用了Http Cache,但在准备Cache数据的逻辑中没有锁处理,数据准备时间过长,就会造成期间大量请求访问数据库。

性能测试报告中SQL Server也显示出周期性达到100% CPU利用率,引发数据库连接超时,同时应用程序出现GATEWAY_TIMEOUT。

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.InvalidOperationException: Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.

 

 

 



分析

因已经做过两轮评审,开发组这次提供了全面的资料,通过代码评审发现逻辑中有使用LDAP(TT快三Win dows活动目录轻量目录访问协议Light Directory Access Protocol)遍历登陆者所有活动目录下的组。

此逻辑可能会产生请求ADFS查询的瓶颈,阻塞请求。

同时发现部分被查询的表中没有创建索引(这个是在最初问过开发团队但得到的回答是肯定的)并进行索引TT快三优化 ,另外,API采用.NET Entity Framework编写,由SQL查询监控看出因无索引导致EF生成相同表的嵌套(笛卡尔积)查询,是导致表遍历和产生表锁的主要原因。

对于大量出现的5xx错误,因上次性能测试没有,主要针对修改的代码进行评审发现增加了EF查询逻辑,这也是导致循环嵌套的原因。


结论

表索引TT快三优化 是主要解决办法。EF查询最终改为明文查询并SQL查询TT快三优化 。


总结

性能问题首先由测试入手,根据测试报告发现错误和性能瓶颈,主要以解决错误消除瓶颈为主要原则。对于有数据库存在的情景,注意查询和索引TT快三优化 ,保证连接池有效支持应用并发。问题调研期间要了解整体架构(本次API嵌套问题和LDAP的使用都是后期由开发组告知)和所使用的TT快三技术 ,才能给出全面建议。从开发组角度应该训练发现性能问题的敏感度。所有问题的发现和解决以测试事实数据说话,不会存在莫须有的性能问题,所有问题皆有因缘。

posted on 2019-06-12 11:09 Richard崔驰坤 阅读(...) 评论(...) 编辑 收藏

导航

TT快三公告