6

앱 엔진에서 실행되는 내 앱에서 주기적이지만 일관된 대기 시간 스파이크가 발생했습니다. 처음에는 네트워크 속도가 느릴 수 있다고 생각했지만 앱 통계는 그렇지 않다고 확인했습니다.낮은 부하에서 앱 엔진 일관된 대기 시간이 급증 함

  • 앱 엔진 SDK : 1.9.42
  • 구글 클라우드 엔드 포인트

    내가 SDK를 이전하고 최신 버전을 사용하여 대기 시간 스파이크를 재현 할 수있었습니다, 현재 나는 다음을 사용하고 있습니다 : 1.9.42

  • 객관화 : 5.1.13
  • Appstats (디버그 네트워크 대기 시간)

그래서 응용 프로그램에 사용이 꽤 리터입니다 흐름, 지난 30 일 동안 나는 0.04 요청에 따라 일반적으로 두 번째 해요 :

대부분의 작업이 아니라 하나 개의 인스턴스로 이루어집니다

requests per second

: enter image description here

대부분의 작업을 '대기 시간은 아래에 잘 두 번째이지만 놀라운 수의 요청은 10-30 배 더 오래 걸립니다.

5% of requests take 23 seconds or longer...

Latency density distribution

그래서 난 그냥 네트워크 대기 시간을해야합니다 생각하지만, 느린 동작의 모든 appstat이를 반증. Datastore와 네트워크는 항상 신뢰할 만합니다.

여기 app stats of operation taking 31 seconds

가 정상적인 요청의 해부학입니다 : 높은 수준에서 enter image description here

내 코드가 꽤 재미있다 : 그것은 간단 여기 30초 인수 느린 요청의 해부학입니다 몇 가지 네트워크 호출을 만들고 클라우드 데이터 저장소에서 데이터를 저장/읽는 API입니다. 전체 소스는 github here에서 찾을 수 있습니다. 앱은 단일 자동 크기 조정 앱 엔진 인스턴스에서 실행되고 예열됩니다. 지난 달 나던 이상

CPU 사용량이 흥미로운 것을 보여주는 것 중 하나 enter image description here

그것은 심지어 코드 불구하고, 심지어 빠른 작업 시간의 거대한 비율이 CPU에 소요되는 것을보고 정말 이상하다 몇 개의 객체를 생성하고 유지하며 JSON을 반환합니다. CPU가 성능 저하를 일으킬 수있는 다른 앱에 의해 내 앱 엔진 인스턴스에 고정되어 있는지 궁금합니다.

<?xml version="1.0" encoding="utf-8"?> 
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> 
    <application>sauce-sync</application> 
    <version>1</version> 
    <threadsafe>true</threadsafe> 
    <automatic-scaling> 
     <!-- always keep an instance up in order to keep startup time low--> 
     <min-idle-instances>1</min-idle-instances> 
    </automatic-scaling> 
</appengine-web-app> 

그리고 내 web.xml 파일은 다음과 같습니다 :

내 appengine.xml 설정은 다음과 같습니다 나는 완전히 붙어있어

<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5"> 
    <servlet> 
     <servlet-name>SystemServiceServlet</servlet-name> 
     <servlet-class>com.google.api.server.spi.SystemServiceServlet</servlet-class> 
     <init-param> 
      <param-name>services</param-name> 
      <param-value>com.sauce.sync.SauceSyncEndpoint</param-value> 
     </init-param> 
    </servlet> 
    <servlet-mapping> 
     <servlet-name>SystemServiceServlet</servlet-name> 
     <url-pattern>/_ah/spi/*</url-pattern> 
    </servlet-mapping> 

    <!--reaper--> 
    <servlet> 
     <servlet-name>reapercron</servlet-name> 
     <servlet-class>com.sauce.sync.reaper.ReaperCronServlet</servlet-class> 
    </servlet> 
    <servlet-mapping> 
     <servlet-name>reapercron</servlet-name> 
     <url-pattern>/reapercron</url-pattern> 
    </servlet-mapping> 

    <servlet> 
     <servlet-name>reaper</servlet-name> 
     <servlet-class>com.sauce.sync.reaper.ReaperServlet</servlet-class> 
    </servlet> 
    <servlet-mapping> 
     <servlet-name>reaper</servlet-name> 
     <url-pattern>/reaper</url-pattern> 
    </servlet-mapping> 


    <welcome-file-list> 
     <welcome-file>index.html</welcome-file> 
    </welcome-file-list> 

    <filter> 
     <filter-name>ObjectifyFilter</filter-name> 
     <filter-class>com.googlecode.objectify.ObjectifyFilter</filter-class> 
    </filter> 
    <filter-mapping> 
     <filter-name>ObjectifyFilter</filter-name> 
     <url-pattern>/*</url-pattern> 
    </filter-mapping> 
</web-app> 

TLDR 나는 방법을 잘 모르겠어요 디버그 또는 수정하여이 문제가 앱 엔진에있는 소규모 앱의 일반적인 비즈니스라고 생각하기 시작했습니다.

잠깐 동안 상주 인스턴스를 끄는 것에 대해 생각하고 있습니다. 내 앱이 방크 하드웨어를 실행하거나 리소스를 많이 소비하는 앱을 실행하고 있기를 바란다. 누구나 비슷한 성능 문제가 발생하거나 앱을 프로파일 링하는 추가 방법을 알고 있습니까?

편집 : 1 개 주민 인스턴스에서 실행하려고했습니다

, 나는 또한 어떤 결과 2-4 per this question에서 동시 요청을 설정하려고했습니다. 로그와 appstats는 코드가 처음 실행될 때까지 기다리는 데 지나치게 많은 시간이 소비되었음을 확인합니다. 첫 번째 코드 행이 실행되기 전에 25 초가 걸리는 요청입니다.이 시점에 어떤 엔드 포인트/앱 엔진이 수행 중인지 확실하지 않습니다.

25 seconds before my code is run

다시로드는 여전히 낮으며,이 요청이 예열 인스턴스입니다.

편집 2 :

는 이유로 애플 리케이션 엔진 + 엔드 포인트 min-idle-instances 세트로 잘 작동 나던 무엇을위한 것 같다. 기본 app engine config로 되돌리면 문제가 해결되었습니다.

enter image description here

+0

은 잠재적으로 관련이 있습니다 (하지만 부하가있는 것으로 보입니다) : http://stackoverflow.com/questions/37307461/what-can-cause-high-variability-of-untraced-time-in-app-engine-requests –

+0

일반적으로 얼마나 많은 인스턴스가 활성화되어 있습니까? 최소 유휴 인스턴스가 1로 설정되어 있어도 새 인스턴스가 올라 오는 데 지연이 없음을 의미하지는 않습니다. – BrettJ

+0

일반적으로 인스턴스 1 개에 인스턴스 수를 그래프로 첨부합니다. 나는 그것이 비록 많은 것을 나타내는 것을 확신하지 못한다. 심지어 부팅되는 콜드 인스턴스조차도 요청을 시작하고 완료하는 데 30 초보다 훨씬 짧다. 높은 대기 시간으로 인해 추가 노드가 생성 될 가능성이 높습니다. 또한 느린 요청은 loading_request가 느린 요청에 설정되어 있지 않기 때문에 첫 번째 인스턴스에서 발생합니다. – sauce

답변

3

나는 대답이 없어,하지만 난 당신에게 몇 가지 디버깅 팁을 제공 할 수 있습니다.

Appstats가 올바르게보고되거나 표시되지 않을 수 있습니다. 그러나 로그 메시지에는 타임 스탬프가 적용됩니다. 각 RPC 작업 후 & 전에 기록하십시오. 그것은 당신에게 약간의 통찰력을 줄 것입니다.

30 초는 예기치 않은 요청과 유사합니다.이 요청은 로그에 명확하게 표시되어야합니다. 과거에 발견 한 한 가지 사실은 트래픽이 적은 앱 (비 직관적으로)에 대한 모든 상주 인스턴스를 설정하면 많은 요청을 차가운 인스턴스로 라우트하는 경향이 있다는 것입니다. 기본 설정을 사용하고 1 분에 1 회 ping 및 엔드 포인트로 cron 태스크를 설정하십시오.

+0

클라우드 콘솔의 앱 통계, 로깅 및 Google 추적 도구는 확인 된 모든 RPC가 일반적으로 매우 빠릅니다. 'loading_request = 1'일 때 느린 요청은 발생하지 않습니다. 나는 당신의 다른 제안을 들여다 보겠다. 나는 거주자의 인스턴스를 너무 많이 수정하려고 노력하지 않았다. 추신 : 나는 Objectify를 좋아한다. – sauce

+0

@stickfigure 워밍업 요청이라면 RPC가 추적 끝으로 클러스터되지 않을 것이다. (인스턴스가 시작된 후에 ** 호출 될 것이므로)? –

+0

실제로 어떤 이유에서든 기본값 설정은 한 번씩 요청을로드해야하는 경우에도 가장 잘 작동합니다. ¯ \\ _ (ツ)) / – sauce