2014-09-17 2 views
0

입력 스트림이 인 getInputStream이 일시적으로 지연되고 간헐적으로 느린 읽기가 발생합니다.HttpURLConnection.getInputStream()에 간헐적 인 지연이있는 이유는 무엇입니까?

서버에서 GET을 실행하기 위해 asynch HttpURLConnection을 사용하고 있습니다. 서버가 XML 문자열을 반환합니다. Fiddler를 사용하여 서버 트랜잭션을보고 있고 서버로 트랜잭션을 보내고 돌아 오는 트랜잭션은 250-600ms 정도 (Android 앱 실행과 관련이 있습니다) 일관됩니다. 실행은 이지만 안드로이드 장치에서는 10 초 이상으로 늘어날 수 있습니다. 나는 같은 무선 네트워크에 스탠드 장치를 사용하여 성능을 시험했지만 동일한 긴 간헐적 인 지연을 봅니다. 때로는 소켓 시간 초과 예외가 발생합니다.

내 앱은 HiSense Android 태블릿에서 실행됩니다. 노트북의 Fiddler 프록시를 통해 안드로이드 트래픽을 안내합니다. 디버그 모드 USB를 통해 일부 타이밍 데이터를 코드에서 캡처하고 있습니다. timer_value는 비동기 작업을 시작할 때 내 작업에 의해 설정됩니다. 로그 시간은 asynchTask의 시작부터 ms 단위로 누적됩니다.

나는 그것이 Fiddler에서 DNS 문제가 아님을 알 수 있습니다. 새 연결을 시작하기 전에 먼저 연결을 닫으려고했습니다. . 나는 "keep-alive"를 끄려고 노력했다. 나는 잠재적 인 영향을 보았습니다 쿠키 동기화 ... 어떤 아이디어? 여기

@Override 
protected String doInBackground(String... urls) { 

    Log.v(LOG_TAG,"top of background = " + Long.valueOf(System.currentTimeMillis() 
     - ((MyApplication)activity.getApplicationContext()).timer_value)); 

    URL url; 
    InputStream is = null; 
    HttpURLConnection connection = null; 

    try { 
     char[] buffer = new char[2000]; 
     int count=0; 
     url = new URL(urls[0]); 

     connection = (HttpURLConnection)url.openConnection(); 
     connection.setDoInput(true); 
     connection.setReadTimeout(10000); 
     connection.setConnectTimeout(15000); 
     connection.setRequestMethod("GET"); 

     Log.v(LOG_TAG,"in front of connect = " + Long.valueOf(System.currentTimeMillis() 
      - ((MyApplication)activity.getApplicationContext()).timer_value)); 

     connection.connect(); 

     Log.v(LOG_TAG,"time to connect = " + Long.valueOf(System.currentTimeMillis() 
      - ((MyApplication)activity.getApplicationContext()).timer_value)); 

     is = connection.getInputStream(); 

     Log.v(LOG_TAG,"time to response = " + Long.valueOf(System.currentTimeMillis() 
      - ((MyApplication)activity.getApplicationContext()).timer_value)); 

     StringBuilder response = new StringBuilder(); 

     Reader reader = new InputStreamReader(is, "UTF-8");   

     while ((count = reader.read(buffer,0,1500)) > 0) {  

      response = response.append(new String(buffer, 0, count)); 
      Log.v(LOG_TAG,"time so far in read loop = " + Long.valueOf(System.currentTimeMillis() 
       - ((MyApplication)activity.getApplicationContext()).timer_value));       

     } 
     is.close(); 
     reader.close(); 

     Log.v(LOG_TAG,"time to read = " + Long.valueOf(System.currentTimeMillis() 
      - ((MyApplication)activity.getApplicationContext()).timer_value));       

     return response.toString(); 

     } 
     catch (Exception e) { 
      Log.v(LOG_TAG,"exception = " + e.toString()); 
      e.printStackTrace(); 
      return null; 
     } 
    }   

대부분의 것보다 더 빠른 로그 캣입니다 : 여기

는 asynchTask에서 코드입니다. Fiddler는 24ms의 트랜잭션을 보여줍니다. 이 심하게 갈 때, 그것은 피들러는 47 밀리 클럭 거래 에 대해 다음과 같은 시간 제한이나 끔찍한 지연을 생성 할 수

09-16 16:21:44.287: V/kinn_nat5(13131): time to connect = 9 
09-16 16:21:44.567: V/kinn_nat5(13131): time to response = 295 
09-16 16:21:44.707: V/kinn_nat5(13131): time to read = 434 
09-16 16:21:44.717: V/kinn_nat5(13131): time to complete = 441 
09-16 16:21:44.757: D/dalvikvm(13131): GC_FOR_ALLOC freed 350K, 11% free 6673K/7495K, paused 21ms, total 21ms 
09-16 16:21:44.847: D/dalvikvm(13131): GC_CONCURRENT freed 281K, 10% free 6813K/7495K, paused 2ms+11ms, total 25ms 

: 나는 441 MS에서 전체 코드를 시간이 초과되었습니다. 여기 나는 18 초에 그것을 시한했다! 어떤 아이디어? 시도 및 디버그이 문제를 위해 정제를 교환 한 후

09-16 16:27:55.217: V/kinn_nat5(14093): top of background = 1 
09-16 16:27:55.217: V/kinn_nat5(14093): time to connect = 9 
09-16 16:28:13.247: V/kinn_nat5(14093): time to response = 18040 
09-16 16:28:14.037: V/kinn_nat5(14093): time to read = 18825 
09-16 16:28:14.087: D/dalvikvm(14093): GC_FOR_ALLOC freed 266K, 11% free 6716K/7495K, paused 52ms, total 52ms 
09-16 16:28:14.097: V/kinn_nat5(14093): time to complete = 18889 
09-16 16:28:14.187: D/dalvikvm(14093): GC_CONCURRENT freed 375K, 10% free 6801K/7495K, paused 1ms+2ms, total 15ms 
+0

나는 Fiddler에 익숙하지 않지만이 프록시를 통해 라우팅하지 않을 때 비슷한 결과를 얻는다 고 가정합니다. 서버가 비난받을 가능성이 있습니까? – mikejonesguy

+0

수정하십시오. 타블렛 만 작동하면 지연이 발생합니다. Fiddler, http://www.telerik.com/fiddler, 플랫폼에서 들어오고 나가는 트래픽을 디버깅 해 봅시다.서버가 http 요청 및 서버에 대한 응답의 타이밍 요약을 살펴봄으로써 서버가 정상적으로 작동하는 것을 확인할 수 있습니다. 브라우저를 사용한 데스크톱 액세스에는 성능 문제가 없습니다. 오늘 밤, 나는 이것이 완료를 기다리고 있고 재사용을 위해 다시 사용할 수있게되기를 기다리는 거래와 관련이 있다고 생각하고 있습니다 ... – user3549463

답변

0

, 나는 이제 근본 원인은 성능이나 내가 사용 된 하이 센스 태블릿의 특정 안드로이드 버전이라고 생각한다.

디버그 모드에서 Android 4.4.4를 실행하는 Asus Nexus 7을 사용할 때 메모리는 같지만 CPU가 훨씬 많고 OS의 최신 버전 인 경우 시스템은 챔피언처럼 수행됩니다. 나는 타임 아웃을 보지 못했고 성능은 피들러 (Fiddler)에서 본 것과 매우 가깝습니다. 시스템은 연결 유지 기능을 사용하거나 사용하지 않고 잘 작동합니다.

왜 Hisense의 성능이 그렇게 나쁜지 나는 잘 모르겠다. 나는 그것을 이해할 시간이 없다. 그 기계는 4.1.1을 실행 중이고 작동이 거의 끝나기 때문에 잘 모르겠습니다. I

다음은 피들러가 440ms에서 클럭 한 전형적인 트랜잭션입니다. 내 타이밍은 509ms에 완료를 보여줍니다.

09-17 12:44:42.880: V/kinn_nat5(10361): top of background = 0 
09-17 12:44:42.880: V/kinn_nat5(10361): in front of connect = 1 
09-17 12:44:42.880: V/kinn_nat5(10361): time to connect = 4 
09-17 12:44:43.381: V/kinn_nat5(10361): time to response = 498 
09-17 12:44:43.391: V/kinn_nat5(10361): time to read = 508 
09-17 12:44:43.391: V/kinn_nat5(10361): time to complete = 509 
09-17 12:44:43.521: D/dalvikvm(10361): GC_FOR_ALLOC freed 800K, 8% free 10280K/11116K, paused 17ms, total 17ms 
+0

백그라운드 프로세스를 0으로 설정하면 HiSense 타블렛의 HTTP 성능이 향상됩니다. 개발자 옵션. – user3549463

관련 문제