성능 - 스프링 부팅 - 서버 응답 시간

성능 - 스프링 부팅 - 서버 응답 시간

스프링 부트 애플리케이션에서 이상한 동작이 발생했습니다.

• 프론트 엔드/클라이언트 - 각도 6
• 백엔드 - 스프링 부트 - 스프링 MVC - 내장 Tomcat - Linux

백엔드를 다시 시작한 후 컨트롤러에 대한 첫 번째 호출에는 약 5초가 소요되며, 다음과 같은 요청은 50ms만 소요됩니다.이것은 90%의 경우에 재현 가능하며, 때로는 첫 번째 통화도 빠릅니다.

확실합니다, 문제는 클라이언트가 아닌 서버에 있습니다.브라우저에서 TTFB 시간(첫 번째 바이트까지의 시간)이 5초로 증가하는 것을 볼 수 있습니다.아래의 요청은 TTFB를 위해 10ms만 필요합니다.

서버의 모니터링 도구(앱 역학)를 사용하면 이러한 느린 서버 호출을 수집할 수 있으며 통화 그래프에서 다음을 확인할 수 있습니다.

org.apache.catalina.webresources.JarWarResourceSet:getArchiveEntries:117

4916ms가 필요합니다.제 생각에 이것이 제 병목 현상입니다.하지만 어떻게 고쳐야 할지 모르겠어요.

이미 시도한 내용:

• hikaricp에서 apache Tomcat jdbc 연결 풀로 전환됨
• 2.0.0에서 2.0.5로 스프링 부트 업그레이드
• Java를 1.8.0_181로 업그레이드
• 속성 spring.jpa.tomcat.testOnBrow = true
• 속성 spring.jpa.tomcat.validation쿼리 = 1개 선택

서버 지연에 영향을 미치지 않는 모든 항목.

갱신하다

전쟁 파일이 여러 번 검색되기 때문에 시간이 손실됩니다.

오르간. 코르티나.웹 리소스.CachedResource.validateResource에서 war 파일(isPackedWarFile)이 있는지 확인하고 있으며 이 검사에서 false를 반환합니다.비록 그것이 전쟁 파일이지만.이 잘못된 행동에 대해 저는 해결책이 있습니다.tomcat.resource.cache-tt를 높은 값으로 설정했습니다.

하지만 지금은 조직.apache.catalina.웹 리소스.Cache.getResource에는 noCache 메서드가 있습니다.그리고 이 메서드에서 클래스 및 jar 파일은 캐시에서 제외됩니다.그리고 이것이 전쟁 파일이 다시 스캔되는 이유입니다.

전체 전쟁 파일을 검색하는 데 약 5초가 걸립니다.그리고 이 휴식은 세계의 휴식을 멈추게 하는 것입니다.그리고 전쟁 파일이 폭발하지 않아 내용을 변경할 수 없기 때문에 이 스캔은 절대로 필요하지 않습니다.

갱신하다

전쟁 파일을 Tomcat 설치에 넣으면 모든 것이 빠릅니다.내장된 Tomcat이 문제입니다.

이미 그렇게 하셨을 것으로 생각합니다만, 그렇지 않다면 https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp 을 보고 거기서 제안된 수정 사항을 구현하십시오.

내장된 Tomcat을 사용하여 검색을 비활성화하려면 여기에 있는 https://github.com/spring-projects/spring-boot/issues/1610 의 의견에 제안이 있습니다.

위의 제안 중 지연을 해결하는 데 도움이 되지 않는 경우 서버 시작 시 첫 번째 요청을 수행하여 지연을 트리거할 수 있습니다.

@SpringBootApplication
public class Application implements CommandLineRunner {

    @Autowired
    private RestTemplate template;

    public static void main (String args[]){
        SpringApplication.run(Application.class, args);
    }

    @Override
    public void run(String... strings) throws Exception {
        // do an initial request from here to trigger scanning the war
        template.exchange(...);
    }

}

이렇게 하면 클라이언트는 더 이상 5초 지연을 경험하지 못할 것입니다.저는 이것이 해킹이라는 것을 알고 있으므로, 만약 당신이 더 깨끗한 방법을 찾는다면 그것을 대신 사용하세요.

CPU 사용량이 많고 응답이 지연되는 비슷한 문제에 직면했습니다.org.apache.catalina.webresources.JarWarResourceSet:getArchiveEntries전쟁 파일을 스캔하는 동안 약 5초가 걸렸습니다.검색하는 동안 요청이 제공되지 않았습니다.

업데이트했습니다.Spring boot version부터1.4.2.RELEASE로.1.5.12.RELEASE이 문제를 해결했습니다.사실, 임베디드 관련 문제가 있었던 것 같습니다.Tomcat이후 버전에서 수정되었습니다.

내장된 Tomcat으로 실행하기 위해 WAR 대신 실행 가능한 JAR 파일을 사용하여 문제를 해결했습니다.이 방법은 실행 파일 아카이브에서 리소스 로드 속도를 높이는 데 권장되는 방법입니다.

1. 하나의 Spring Boot 프로젝트를 가지고 JAR 또는 WAR에 배포할 수 있습니다.
2. 저는 더 나은 성능을 위해 WAR에서 JAR로 전환해야 했고 프리마커에서 JSP 태그립을 사용할 때 문제가 있었습니다.이것은 JSP 태그립을 사용할 때 해당 문제를 해결하는 방법입니다.

당신이 설명하는 것은 무거운 DB 연결 풀링을 사용하는 인프라에 대한 재부팅의 일반적인 효과입니다.

• 첫 번째 요청: 물리적 연결 열기(100ms ~ 2-3초), 초기화 수행(DB에 따라 다름), SQL 수행(쿼리마다 다름), 풀로 돌아가기(1ms 미만)
• 두 번째 요청: 풀에서 추출(<1ms), SQL 수행(쿼리마다 다름), 풀로 돌아가기(<1ms)

데이터에 따르면 처음 두 단계는 느리고 DB 풀이 준비될 때까지 매우 느린 쿼리를 경험하게 될 것입니다.잠재적인 개선 사항은 다음과 같습니다.

• Tomcat이 아직 응답하지 않는 동안 풀이 자체 초기화를 수행하는 준비 기간 구성
• 연결을 설정해야 하는 경우 DB 측과 앱 측에서 연결 생성 시 수행되는 작업을 확인합니다.

언급URL : https://stackoverflow.com/questions/52648831/performance-spring-boot-server-response-time