종종 Google 크롬의 네트워크 패널을 사용하여 성능 문제를 해결할 때 다른 시간을보고 그 의미가 무엇인지 궁금합니다.
누군가 내가 이것을 제대로 이해하고 있는지 확인할 수 있습니까?
- 차단 : 동일한 도메인 제한 (???)에 대한 브라우저의 여러 요청에 의해 차단 된 시간
- 대기 중 : 서버에서 연결 대기 중 (???)
- 전송 : 서버에서 브라우저로 파일을 전송하는 데 소요 된 시간 (???)
- 수신 : 브라우저가 파일 (???)을 분석하고 디코딩하는 데 소요 된 시간
- DNS 조회 : 호스트 이름을 확인하는 데 소요 된 시간입니다.
- 연결 : 소켓 연결을 설정하는 데 소요 된 시간입니다.
이제 누군가가 긴 차단 시간을 어떻게 고칠까요?
이제 누군가가 긴 대기 시간을 어떻게 고칠까요?
답변
보내기는 데이터 / 요청을 서버에 업로드하는 데 소요되는 시간입니다. 차단과 대기 사이에 발생합니다. 예를 들어 ASPX 페이지를 다시 게시하면 요청 (양식 및 세션 상태의 값 포함)을 다시 ASP 서버로 업로드하는 데 걸린 시간을 나타냅니다.
대기는 요청이 전송 된 후 서버로부터 응답을 받기 전까지의 시간입니다. 기본적으로 이것은 서버의 응답을 기다리는 데 소요 된 시간입니다.
수신은 서버에서 응답을 다운로드하는 데 소요 된 시간입니다.
차단 은 요청을 시작하는 UI 스레드와 연결되는 HTTP GET 요청 사이의 시간입니다.
발생하는 순서는 다음과 같습니다.
- 블로킹*
- DNS 조회
- 연결
- 배상
- 기다리는
- 전수
* 차단 및 DNS 조회가 바뀔 수 있습니다.
네트워크 탭에는 처리에 소요 된 시간이 표시되지 않습니다.
차단 시간이 길면 브라우저를 실행하는 컴퓨터가 느리게 실행됩니다. 머신을 업그레이드하거나 (더 많은 RAM, 더 빠른 프로세서 등) 워크로드를 줄임 (필요하지 않은 서비스 끄기, 프로그램 종료 등)하여이 문제를 해결할 수 있습니다.
대기 시간이 길면 서버가 요청에 응답하는 데 시간이 오래 걸린다는 것을 나타냅니다. 이것은 다음을 의미합니다.
- 요청을 처리하는 데 오랜 시간이 걸립니다 (예 : 데이터베이스에서 많은 양의 데이터를 가져 오는 경우, 많은 양의 데이터를 정렬해야하거나 회전해야하는 HDD에서 파일을 찾아야하는 경우).
- 서버가 적절한 시간 내에 모든 요청을 처리하기에는 너무 많은 요청을 받고 있습니다 (요청을 처리하는 데 0.02 초가 걸릴 수 있지만 1000 개의 요청이있는 경우 눈에 띄게 지연됩니다).
두 가지 문제 (긴 대기 + 긴 차단)는 관련이 있습니다. 캐싱, 새 서버 추가, 활성 페이지에 필요한 작업 감소를 통해 서버의 워크로드를 줄일 수 있다면 두 영역 모두에서 개선 된 사항을 확인해야합니다.
답변
여기에서 Google 팀 의 자세한 공식 설명 을 읽을 수 있습니다 . 정말 유용한 리소스이며 정보는 타임 라인보기 섹션 아래에 있습니다 .
리소스 네트워크 타이밍 은 타임 라인보기의 리소스 표시 줄과 동일한 정보를 표시합니다. 질문에 답하기 :
- DNS 조회 : DNS 조회를 수행하는 데 소요 된 시간입니다. (site.com의 IP 주소를 찾아야하는데 시간이 걸립니다)
- 차단 : 이미 설정된 연결을 재사용 할 수있을 때까지 대기하는 데 소요 된 시간입니다. 다른 답변에서 말했듯이 서버에 의존하지 않습니다-이것은 클라이언트의 문제입니다.
- 연결 : TCP 핸드 셰이크 / 재시도, DNS 조회, 프록시 연결 또는 SSL (Secure-Socket Layer) 협상을 포함하여 연결을 설정하는 데 걸린 시간입니다. 네트워크 정체에 따라 다릅니다.
- 보내기 -요청을 보내는 데 소요 된 시간입니다. 전송 된 데이터의 크기 (큰 이미지 또는 많은 양의 텍스트를 제출하는 경우를 제외하고는 거의 항상 몇 바이트이므로 요청이 거의 없기 때문에 대부분 작음), 네트워크 정체, 클라이언트와 서버의 근접성에 따라 다릅니다.
- 대기 -초기 응답을 기다리는 데 소요 된 시간입니다. 이것은 대부분 서버가 응답을 처리하고 응답하는 시간입니다. 이것은 서버가 사물을 계산하고 데이터베이스에서 레코드를 가져 오는 등의 속도입니다.
- 수신 -응답 데이터를 수신하는 데 소요 된 시간입니다. 보내는 것과 비슷하지만 이제 서버에서 데이터를 가져옵니다 (응답 크기는 대부분 요청보다 큽니다). 따라서 크기, 연결 품질 등에 따라 다릅니다.
답변
차단 : 이미 설정된 연결을 재사용 할 수있을 때까지 대기하는 데 소요 된 시간입니다. 다른 답변에서 말했듯이 서버에 의존하지 않습니다 . 이것은 클라이언트의 문제 입니다.
위의 내용에 동의하지 않습니다. 다른 모든 것은 동일합니다 [내 컴퓨터 작업량]-내 브라우저는 한 웹 사이트에 대해 “차단”시간이 매우 적고 다른 웹 사이트에 대해 긴 차단 시간을 표시합니다.
따라서 6 개 스레드 + 프록시 협상 ** 중 하나를 기다리는 것이 높은 경우, 이는 대부분 서버 속도 저하 또는 잘못된 페이지 디자인 (너무 많은 시간이 너무 많이 전송 됨)의 연쇄 효과 때문입니다.
**- “Proxy Negotiation”이 무엇을 의미하든간에, 특히 로컬 / CDN 프록시가 실제로 관련되지 않은 경우 아무도 이것을 잘 설명하지 않습니다.
