WebApi 接口调用的时候CUP飙升到100%的解决方案
0
最佳答案
0
WebApi升到100%的情况很少吧，一群都是内存爆，就是客户端传了超大的数据给你，而且恰好用的是32位运行时。而且，即时峰值一不小心到了100%也不是什么大问题，服务扛100%的压力是硬要求，只要不一直100%就可以了。很IIS并发数适当地往下压一压，让来的多余的请求排队或者超时，宁愿让用户多的时候少数人进不来，也不能让进来太多在把你服务器撑爆了。并发数限定合适，服务器崩溃的事情你一般就不用担心了。即使有DDOS攻击你的服务器也不会崩，只是有人进不来。
收获园豆：10
嗯嗯 谢谢的你回复；我忘记说明情况了；发生这个CUP 达到100%是在基本上没有用户访问量上发生的；这是在内部测试的时候发生；根据日志分析出来两个接口；一个是接口是返回了一个字符串（获取一张图片的url地址）；另一个接口是返回是list 集合（数据只有6条）；发生的很诡异，不是问题代码出现哪里呢.
@IT小伙儿: 如果是测试的话，因素就多了，首先，你没办法肯定这个是webapi出的问题，有可能是你操作系统出的问题，甚至有可能是杀毒软件，也有可能是iis本身，如果在vs里面调试的时候出现，那就更没有参考意义了。正常接口卡死，也就只有出现死循环的情况，别的都不存在，现在的所有互调都是超时设置，一旦超时都是跳出。
@ensleep: 嗯嗯你上述说的问题，我们都考虑过了；服务器上很干净就跑这一个程序，没有其他程序运行；其次是我们有两台服务器的，环境配置都是一样的，出现问题后就将另一台服务器启动了；到目前为止，两台服务器都没有出现过这种情况；关于代码中的循环，可以说在代码中就特别的少，关于带有循环的代码我都分析过确定没有问题，还有对对象的关闭操作。
@IT小伙儿: 如果无法重现问题，这个就比较难了。建议每次服务更新后都预加载一遍，使得后面每次调用都是常规调用，防止 首次运行时出现异常或者大量加载导致性能波动，其它我真的帮不了你了。
@ensleep: 嗯嗯 好的 谢谢；现在出了一个临时的解决方案 就是当CUP 达到70%的时候 就让IIS 自动重新启动了
其他回答(3)
0
查看请求日志,找出处理时间长的请求
根据日志分析；分别查看了IIS日志和程序运行的日志；根据时间点分析出了两个接口；在这个时候调用了；可是两个接口一个是返回的字符串一个返回的是list集合的操作（集合的数据就6条）可以忽略数据量的问题了；
0
来围观一下，学习学习
0
做一个日志记录,在你的API里面调用的函数或使用的循环前后都加上时间标记,最后输出,看看是什么地方耗时很多,然后再剥离出来单独测试.
