초기 연결

초기 연결에는 SSL 협상이 포함되므로 핸드 셰이크가 높기 때문에 SSL 설정 방식에 심각한 문제가 있음을 나타내는 좋은 지표입니다.

Chrome : 리소스 타이밍 이해

TCP 핸드 셰이크 / 재시도 및 SSL 협상을 포함하여 연결을 설정하는 데 걸린 시간입니다.

SSL 핸드 셰이크 및 TTFB

SSL 핸드 셰이크를 완료하는 데 소요 된 시간과 TTFB를 기다리는 서버 (첫 바이트까지의 시간)라는 두 가지 주요 문제가 있습니다.

• TTFB : 4079ms (1000ms 미만이어야 함)
• SSL 핸드 셰이크 11830ms (100ms 미만이어야 함)

또한 3G / 4G 장치로 테스트 할 때 전화 신호의 강도가 다양하기 때문에 첫 바이트가 더 길어질 수 있습니다. 이로 인해 간헐적 인 연결 문제와 지연 시간이 달라질 수 있습니다.

1 단계 : SSL 문제 조사

SSL에 심각한 문제가 있으며 OpenSSL 또는 이와 유사한 설치에 결함이있을 가능성이 높습니다. SSL Labs를 사용하여 SSL 인증서를 테스트 한 다음 제안 된 문제 또는 경고를 수정하십시오.

SSL이 여전히 느리게 작동하는 경우 서버 과부하 또는 서버 오류 일 가능성이 큽니다. 나중에 발생하면 결함이있는 곳을 좁히려 고 노력해야합니다. 이 문제에 대한 추가 지원이 필요한 경우 서버 결함 스택을 사용하십시오. 한 사용자가 새 키를 작성하면 느리거나 느린 SSL 문제 를 해결했다고보고했습니다 .

서버 리소스 문제인 경우로드 밸런서가 도움이 될 수 있습니다.

2 단계 : TTFB 조사

SSL 문제를 조사한 후에도 여전히 TTFB가 증가하면 서버에 충분한 자원이 있는지 확인하여 서버를 테스트해야합니다.

첫 번째 바이트 시간은 다음의 영향을 받지만 다음에 제한되지 않습니다.

• 서버를 호스팅하는 사용자에서 데이터 센터까지의 거리는 TTFB를 증가시킬 수 있습니다
• 캐시되지 않은 GZIP는 TTFB를 증가시킬 수 있습니다
• 혼잡 한 네트워크는 TTFB를 증가시킬 수 있습니다
• 혼잡 한 서버는 TTFB를 증가시킬 수 있습니다

때때로 CPU와 RAM을 늘리는 것이 항상 최선의 방법은 아닙니다. 때로는 여러 서버를 나란히 쉽게 실행할 수있을뿐만 아니라 캐싱 및 SSL 요청을 실제로 오프로드하기 때문에 로드 밸런서 를 도입하는 것이 좋습니다 . 다른 장점은 다음과 같습니다.

출처

• 캐싱 : 어플라이언스는 이미지와 같이 변경되지 않는 컨텐츠를 저장하고 웹 서버로 트래픽을 보내지 않고 클라이언트에 직접 제공 할 수 있습니다.
• 압축 : 파일을 보내기 전에 압축하여 HTTP 객체의 트래픽 양을 줄입니다.
• SSL 오프로드 : 웹 서버의 CPU에서 SSL 트래픽 처리가 필요하므로로드 밸런서가 대신이 처리를 수행 할 수 있습니다.
• 고 가용성 : 하나의 장애가 발생한 경우 두 개의로드 밸런싱 어플라이언스를 사용할 수 있습니다.

TTFB를 낮추기위한 팁 :

• 데이터베이스가 동일한 네트워크 또는 양질의 SQL 클라우드 에 있는지 확인하십시오 .
• 데이터베이스가 메모리에서 읽어되어 있는지 확인 NEVER EVER 스왑 파일!
• (A)의 만들기 사용하는 콘텐츠 전달 네트워크 , 그것은 서버 요청 및 압축 작업을 오프로드.
• Varnish Cache 를 사용하여 페이지를 캐싱하여 데이터베이스의로드를 줄입니다.
• HDParm을 사용하여 하드 디스크에서 정적 파일 벤치마킹
• Apache HTTP 서버 벤치마킹 도구를 사용하여 서버 벤치 마크
• WebPageTest를 사용하여 여러 원격 위치에서 10 번의 패스로 웹 사이트 벤치마킹

답변