小心服務器內存居高不下的元凶----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到底是怎么一回事），其實解決它也應該是個必然的結果！

 

路漫漫而修遠，吾將上下而求索~~