각 요청에는 70밀리초가 걸리므로 1개의 CPU 코어는 초당 1000/70=14개의 요청만 처리할 수 있으며, 4개의 CPU 코어는 56개의 요청만 처리할 수 있습니다. Ubuntu(i5-3230M)에서 WordPress를 실행하기 위한 PHP7+OPcache, 1개의 CPU 코어가 1개의 WordPress 홈페이지 요청을 처리하고(데이터베이스를 확인할 캐시가 필요하지 않음), 시간은 28밀리초에 불과합니다. WordPress는 성능 집약적이라는 것을 알아야 합니다. 좋은 PHP 프로그램입니다. 따라서 각 요청이 빠른 것으로 간주되려면 최소 10밀리초가 소요되어야 한다고 생각합니다. 결국 Nginx는 웹사이트의 디렉토리 목록을 표시합니다. 루트 디렉터리에는 1밀리초밖에 걸리지 않습니다.
이렇게 말하면 Servlet을 사용하여 간단한 페이지를 직접 작성하는 것이 빠를 수도 있지만, 모든 기능을 직접 완성해 보면 SpringMVC만큼 빠르지도 않고, 많은 기능을 수행한다는 것을 알 수 있습니다. 실제로 SpringMVC와 같은 프레임워크에서는 이미 사용 가능합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
각 요청에는 70밀리초가 걸리므로 1개의 CPU 코어는 초당 1000/70=14개의 요청만 처리할 수 있으며, 4개의 CPU 코어는 56개의 요청만 처리할 수 있습니다. Ubuntu(i5-3230M)에서 WordPress를 실행하기 위한 PHP7+OPcache, 1개의 CPU 코어가 1개의 WordPress 홈페이지 요청을 처리하고(데이터베이스를 확인할 캐시가 필요하지 않음), 시간은 28밀리초에 불과합니다. WordPress는 성능 집약적이라는 것을 알아야 합니다. 좋은 PHP 프로그램입니다.
따라서 각 요청이 빠른 것으로 간주되려면 최소 10밀리초가 소요되어야 한다고 생각합니다. 결국 Nginx는 웹사이트의 디렉토리 목록을 표시합니다. 루트 디렉터리에는 1밀리초밖에 걸리지 않습니다.
사실 웹 애플리케이션에서는 70ms도 그리 느리지 않습니다.
사용자 경험에 영향을 미친다고 생각된다면 순수 HttpServlet과 비교해 보세요. 페이지 로딩 시간에 영향을 미치는 요소는 많습니다. 긴 지연은 반드시 Spring MVC로 인해 발생하는 것은 아니지만 컨테이너 및 브라우저와 같은 요소와 관련이 있습니다.
당신이 작성한 코드와도 일정한 관계가 있습니다. . .
요청 응답 속도가 너무 느린지는 코드와 실제 상황을 살펴봐야 합니다. 일반적으로 소규모 시스템에 대한 최상의 최적화는 캐시를 추가하여 데이터베이스 요청을 줄이고 메모리에서 직접 데이터를 가져오는 것입니다. 훨씬 더 빨라질 거예요!
다음을 살펴보시기 바랍니다: https://my.oschina.net/xiangg...
이는 주로 Spring의 뷰 렌더링 메커니즘과 관련이 있습니다. 다음을 참조하세요: http://www.cnblogs.com/davidw...
이렇게 말하면 Servlet을 사용하여 간단한 페이지를 직접 작성하는 것이 빠를 수도 있지만, 모든 기능을 직접 완성해 보면 SpringMVC만큼 빠르지도 않고, 많은 기능을 수행한다는 것을 알 수 있습니다. 실제로 SpringMVC와 같은 프레임워크에서는 이미 사용 가능합니다.
너무 느리지는 않은 것 같아요
70ms이 정도의 시간은 사용자에게 완전히 무감각하기 때문에 여전히 상대적으로 빠릅니다.프런트엔드와 백엔드를 분리한 다음 GET 요청을 캐시합니다. 물론 70ms는 이미 매우 빠른 속도입니다.