内存这东西虽然便宜,白菜价,但实际在我们的互联网环境中还是非常珍贵的资源,谁叫它不能像硬盘似的,随便弄一块就有好几百G,而没内存就准备挂吧!
话说回来,这次分享的主要是我们在使用调用WebAPI 时的内存竟然居高不下,和解决方法,先上一段代码:
using System.Collections.Generic;
using System.Net;
using System.Net.Http;
using System.Net.Http.Formatting;
using System.Net.Http.Headers;
namespace EBizClient.Common
{
public enum MediaTypeHeader
{
application_json,
application_xml
}
public class HttpClientHelper
{
public MediaTypeHeader mediaType{ get; set;}
public HttpClientHelper(){
this.mediaType = MediaTypeHeader.application_json;
}
public HttpResponseMessage Get( string url)
{
var client = new HttpClient();
var response = client.GetAsync(url).Result;
return response;
}
}
}
这段代码主要是做了一个简单的封装,方便前端调用WebAPI返回的rest服务,初看是没啥问题,而且挺长一段时间内我们也就这样用了!
突然有一天测试人员告诉我,程序死了,测试机器卡死了,究其原因,在做压力测试的时候内存没了,但“释压”以后,依然霸占着内存不肯放,只能硬重启。这可是个大问题,我们就这样重复试验,每次结果都一样,去“压”哪个服务,那个服务的IIS进程占用内存就只进不出了。根据这种场景,我们定位问题要么在数据访问层(可能性不大,我们用了比较成熟的框架),要么就是在数据缓存逻辑那边出了问题(但监测下来存在缓存中的数据少的可怜啊)。
折腾了一段时间,静下心来,分析问题发觉我们根本就是找错了方向,一个同事提醒会不会是web服务一直占用着没有释放呢?在“重压”之下,有些服务无法得到及时响应,但自己又不会释放,越积越多,形成当前局面,从这个思路下手,修正一下代码:
{
var client = new HttpClient();
HttpResponseMessage response = null;
client.GetAsync(url).ContinueWith(
(requestTask) =>
{
response = requestTask.Result;
}).Wait( 60000);
return response;
}
这段代码就是在其异步调用服务的时候给一个响应时间,如果这个服务1分钟都没有响应,则自动停止释放掉,到此,这个郁闷的问题就被解决了!
这也是采用新框架尤其需要谨慎的地方,这个问题的解决虽然带有一定的偶然性,但如果真正了解http协议的本源(最基础的无非就是request和response到底是怎么一回事),其实解决它也应该是个必然的结果!
路漫漫而修远,吾将上下而求索~~
欢迎加入项目管理讨论群:261830264