우리는 고객과 관련하여 주위를 돌아 다니며 상당한 시간을 보냈습니다. 그들은 원래 뉴욕에서 주최했으며 직원들은 대부분 보스턴 지역에 있습니다. 그들은 서버를 전국의 약 3 분의 2의 덴버에있는 우리 시설로 옮기고있었습니다.

이사를 마치면 본사의 Comcast 링크에서 성능 문제가 발생하기 시작했습니다. 그들은 <10ms의 대기 시간을 가졌으며 최대 80-ish ms에 달했습니다. 그들은 그들의 사이트에 도달하는 속도가 느리다는 것을 알아 차렸다. 그들은 지리적으로 인해 한계가 있으며 서해안의 사용자가 잠재적으로 더 나은 성능을 얻을 수 있음을 알고있는 것처럼 보였습니다.

우리는 몇 번왔다 갔다했다. 약 6 개월 후,이 클라이언트와 관련이없는 이유로 (더 나은 가격, 더 많은 대역폭, 다른 공급 업체의 유지 보수 기간에 만족하지 않는) 다른 공급 업체와 다른 기본 업스트림 ISP로 전환했으며 새로운 공급 업체와 함께 약 45ms를 얻었습니다. 이 클라이언트의 평균 대기 시간. 이 시점에서 성능 문제가 사라진 것 같습니다.

이러한 종류의 문제가 발생한 사례와 관련 사례에 대한 경험을 제공하기 위해.

“mtr”을 사용하여 다른 원격 엔드에 대기 시간 및 패킷 손실에 대한 정보를 표시하십시오. “느린 경로”라우팅을 완전히 이해하지 않으면 해당 출력에 표시된 마지막 홉 이외의 것은 무시하십시오. Van Jacobson은 인간이 400ms에서 대기 시간을 감지하지만 많은 연결에서 여러 번의 교환 교환이 필요하다는 것을 알고 100ms 대기 시간은 최대 1 초를 빠르게 추가 할 수 있습니다 …

내 경험상 250ms의 대기 시간이 눈에 띄게 느린 연결처럼 느껴지기 시작합니다. 10ms 이상은 타오르는 연결처럼 느껴집니다. 그것은 실제로 당신이하고있는 것에 달려 있습니다.

션

답변