小心服务器内存居高不下的元凶----WebAPI服务

内存这东西虽然便宜,白菜价,但实际在我们的互联网环境中还是非常珍贵的资源,谁叫它不能像硬盘似的,随便弄一块就有好几百G,而没内存就准备挂吧!

话说回来,这次分享的主要是我们在使用调用WebAPI 时的内存竟然居高不下,和解决方法,先上一段代码:

 

using System;
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服务一直占用着没有释放呢?在“重压”之下,有些服务无法得到及时响应,但自己又不会释放,越积越多,形成当前局面,从这个思路下手,修正一下代码:

 

 public HttpResponseMessage Get(string url)
        {
            var client = new HttpClient();
            HttpResponseMessage response = null;
            client.GetAsync(url).ContinueWith(
             (requestTask) =>
             {
                 response = requestTask.Result;

             }).Wait(60000);
            return response;
        }

这段代码就是在其异步调用服务的时候给一个响应时间,如果这个服务1分钟都没有响应,则自动停止释放掉,到此,这个郁闷的问题就被解决了!

这也是采用新框架尤其需要谨慎的地方,这个问题的解决虽然带有一定的偶然性,但如果真正了解http协议的本源(最基础的无非就是request和response到底是怎么一回事),其实解决它也应该是个必然的结果!

 

路漫漫而修远,吾将上下而求索~~

 

posted on 2012-07-23 13:50  *深海  阅读(5051)  评论(4编辑  收藏  举报

我是深海,每天都在进步着~~