초기 계획 및 성능 기록을 사용하여 Office 365 성능 조정
Office 365 비즈니스 간의 연결 성능을 검사 몇 가지 간단한 방법으로 연결의 대략적인 기준을 설정할 수 있습니다. 클라이언트 컴퓨터 연결의 성능 기록을 알면 새로운 문제를 조기에 감지하고 문제를 식별하고 예측하는 데 도움이 될 수 있습니다.
성능 문제를 해결하는 데 익숙하지 않은 경우 이 문서는 몇 가지 일반적인 질문을 고려하는 데 도움이 되도록 설계되었습니다. 표시되는 문제가 Office 365 서비스 인시던트가 아닌 성능 문제인지 어떻게 알 수 있나요? 장기적으로 좋은 성능을 계획하려면 어떻게 할까요? 성능을 어떻게 주시할 수 있나요? 팀 또는 클라이언트가 Office 365 사용하는 동안 성능이 느려지고 이러한 질문에 대해 궁금한 경우 계속 읽어보세요.
중요
현재 클라이언트와 Office 365 간에 성능 문제가 있나요? Office 365 성능 문제 해결 계획에 설명된 단계를 따릅니다.
Office 365 성능에 대해 알아야 할 사항
Office 365 자동화 및 실제 사용자에 의해 모니터링되는 대용량 전용 Microsoft 네트워크 내에 있습니다. Office 365 클라우드 유지 관리의 일부는 가능한 경우 성능 조정 및 간소화입니다. Office 365 클라우드의 클라이언트는 인터넷을 통해 연결해야 하므로 Office 365 서비스 전반에서 성능을 미세 조정하기 위한 지속적인 노력이 진행되고 있습니다.
성능 향상은 실제로 클라우드에서 멈추지 않으므로 클라우드를 건강하고 빠르게 유지하는 경험도 없습니다. 위치에서 Office 365 연결하는 성능 문제가 있는 경우 지원 사례로 시작하거나 기다리지 않는 것이 가장 좋습니다. 대신 '내부 외부'에서 문제를 조사해야 합니다. 즉, 네트워크 내부에서 시작하여 Office 365. 지원으로 사례를 열기 전에 데이터를 수집하고 문제를 탐색하고 resolve 수 있는 작업을 수행할 수 있습니다.
중요
Office 365 용량 계획 및 제한에 유의하세요. 이 정보는 성능 문제를 resolve 때 곡선보다 앞서나갈 것입니다. 다음은 Microsoft 365 및 Office 365 서비스 설명에 대한 링크입니다. 중앙 허브이며 Office 365 제공하는 모든 서비스에는 여기에서 자체 서비스 설명으로 연결되는 링크가 있습니다. 즉, SharePoint에 대한 표준 제한을 확인해야 하는 경우 예를 들어 SharePoint 서비스 설명을 클릭하고 SharePoint 제한 섹션을 찾습니다.
성능이 슬라이딩 스케일임을 이해하여 문제 해결에 들어가야 합니다. 이상화된 가치를 달성하고 영구적으로 유지하는 것이 아닙니다. 많은 수의 사용자를 온보딩하거나 대규모 데이터 마이그레이션을 수행하는 것과 같은 대역폭이 많은 작업은 스트레스가 많으므로 성능에 미치는 영향을 계획 합니다. 성능 목표에 대한 대략적인 아이디어가 있어야 하지만 많은 변수가 성능에 영향을 주므로 성능이 달라집니다.
성능 문제 해결은 특정 목표를 달성하고 해당 숫자를 무기한 유지하는 것이 아니라 모든 변수를 고려하여 기존 활동을 개선하는 것입니다.
성능 문제는 어떤 모습인가요?
먼저 발생한 것이 실제로 서비스 인시던트가 아닌 성능 문제인지 확인해야 합니다. 성능 문제는 Office 365 서비스 인시던트와 다릅니다. 여기에 그들을 구별하는 방법입니다.
서비스 인시던트 는 Office 365 서비스 자체에 문제가 있을 때 발생합니다. Microsoft 365 관리 센터 현재 상태 아래에 빨간색 또는 노란색 아이콘이 표시될 수 있습니다. Office 365 연결하는 클라이언트 컴퓨터의 성능이 느릴 수 있습니다. 예를 들어 현재 상태가 빨간색 아이콘을 보고하고 Exchange 옆에 조사가 표시되는 경우 Exchange Online 사용하는 클라이언트 사서함이 느리다는 불만을 제기하는 organization 사용자로부터 전화를 받을 수도 있습니다. 이 경우 Exchange Online 성능이 서비스 문제의 피해자라고 가정하는 것이 합리적입니다.
이 시점에서 Office 365 관리자는 현재 상태를 검사 다음 세부 정보 및 기록을 자주 확인하여 시스템의 유지 관리를 최신 상태로 유지해야 합니다. 현재 상태 dashboard 서비스의 변경 내용 및 문제를 업데이트하기 위해 만들어졌습니다. 상태 기록, 관리자에게 기록된 메모 및 설명은 측정을 돕고 진행 중인 작업에 대한 게시를 유지하는 데 도움이 됩니다.
인시던트가 성능 저하를 일으킬 수 있지만 성능 문제는 서비스 인시던트가 아닙니다. 성능 문제는 다음과 같습니다.
현재 상태 관리 센터에서 서비스에 대해 보고하는 내용에 관계없이 성능 문제가 발생합니다.
흐름에 사용되는 동작은 완료하는 데 시간이 오래 걸리거나 완료되지 않습니다.
문제를 복제하거나 올바른 일련의 단계를 수행하는 경우 발생하는 것을 알 수 있습니다.
문제가 간헐적으로 발생하면 여전히 패턴이 있을 수 있습니다. 예를 들어 오전 10시까지는 항상 Office 365 액세스할 수 없는 사용자의 전화를 받게 됩니다. 통화는 정오무렵에 종료됩니다.
이 목록은 아마 익숙한 것 같습니다. 너무 익숙할 수도 있습니다. 성능 문제가 있다는 것을 알게 되면 질문은 "다음에 무엇을 해야 할까요?" 가 됩니다. 이 문서의 나머지 부분을 통해 정확하게 확인할 수 있습니다.
성능 문제를 정의하고 테스트하는 방법
성능 문제는 시간이 지남에 따라 자주 발생하므로 실제 문제를 정의하기가 어려울 수 있습니다. 문제 컨텍스트에 대한 좋은 생각으로 좋은 문제 설명을 Create 다음 반복 가능한 테스트 단계를 수행해야 합니다. 다음은 충분한 정보를 제공하지 않는 문제 문의 몇 가지 예입니다.
받은 편지함에서 내 일정으로 전환하는 것은 예전에는 눈치채지 못했던 것이었고, 지금은 커피 브레이크가 되었습니다. 예전처럼 작동할 수 있나요?
내 파일을 SharePoint에 업로드하는 것은 영원히 걸립니다. 왜 오후에 느리지만, 다른 시간에는 빠릅니다. 그냥 빠를 수 없습니까?
위의 문제 설명에 의해 제기되는 몇 가지 큰 문제가 있습니다. 특히 모호성이 너무 많아서 처리할 수 없습니다. 예를 들면
받은 편지함과 일정 간에 전환하는 것이 노트북에서 작동하는 데 어떻게 사용되었는지는 불분명합니다.
사용자가 "빠를 수 없습니다"라고 말하면 "빠름"은 무엇인가요?
얼마나 오래 "영원히"입니까? 몇 초입니까? 아니면 몇 분? 아니면 사용자가 점심을 먹을 수 있고 작업이 돌아온 후 10 분 후에 끝날 수 있습니까?
관리자 및 문제 해결사에서는 다음과 같은 일반 문에서 문제의 세부 정보를 알 수 없습니다. 예를 들어 문제가 언제 발생하는지 알 수 없습니다. 문제 해결사에서는 사용자가 집에서 작업하는 것을 모르고 홈 네트워크에 있는 동안만 느린 전환만 볼 수 있습니다. 또는 사용자가 로컬 클라이언트에서 다른 RAM 집약적 애플리케이션을 실행합니다. 관리자는 사용자가 이전 운영 체제를 실행 중인지 또는 최근 업데이트를 실행하지 않았는지 모를 수 있습니다.
사용자가 성능 문제를 보고할 때 수집해야 할 많은 정보가 있습니다. 정보를 가져오고 기록하는 것을 문제의 범위 지정이라고 합니다. 다음은 성능 문제에 대한 정보를 수집하는 데 사용할 수 있는 기본 범위 목록입니다. 이 목록은 완전하지는 않지만 시작할 수 있는 장소입니다.
문제가 발생한 날짜와 낮이나 밤의 시간 정도는 무엇인가요?
어떤 종류의 클라이언트 컴퓨터를 사용했으며 비즈니스 네트워크(VPN, 유선, 무선)에 연결하려면 어떻게 해야 할까요?
원격으로 일하고 있었거나 사무실에 있었나요?
다른 컴퓨터에서 동일한 작업을 시도하고 동일한 동작을 확인했나요?
수행하는 작업을 작성할 수 있도록 문제를 제공하는 단계를 안내합니다.
성능은 몇 초 또는 몇 분 정도 느려지나요?
당신은 어디에 있습니까?
이러한 질문 중 일부는 다른 질문보다 더 분명합니다. 대부분의 모든 사용자는 문제 해결사에게 문제를 재현하기 위한 정확한 단계가 필요하다는 것을 이해합니다. 결국 무엇이 잘못되었는지 어떻게 기록할 수 있으며 문제가 해결되었는지 어떻게 테스트할 수 있나요? "어떤 날짜와 시간에 문제가 발생했나요?", "전 세계 어디에 있나요?"와 같은 정보는 함께 사용할 수 있습니다. 사용자가 작업하는 시기에 따라 몇 시간의 시간 차이로 회사 네트워크 일부에서 유지 관리가 이미 진행 중임을 의미할 수 있습니다. instance 경우 회사는 하이브리드 SharePoint Search 같은 하이브리드 구현을 가지고 있으며, Microsoft 365의 SharePoint와 온-프레미스 SharePoint Server 2013 instance 모두의 검색 인덱스를 쿼리할 수 있으며, 온-프레미스 팜에서 업데이트가 진행 중일 수 있습니다. 회사가 모두 클라우드에 있는 경우 시스템 유지 관리에는 네트워크 하드웨어 추가 또는 제거, 회사 전체 업데이트 배포 또는 DNS 또는 기타 핵심 인프라 변경이 포함될 수 있습니다.
성능 문제를 해결할 때는 범죄 현장과 비슷합니다. 증거에서 결론을 도출하려면 정확하고 관찰해야 합니다. 이렇게 하려면 증거를 수집하여 좋은 문제 진술을 가져와야 합니다. 여기에는 컴퓨터의 컨텍스트, 사용자의 컨텍스트, 문제가 시작된 시점 및 성능 문제를 노출한 정확한 단계가 포함되어야 합니다. 이 문제 설명은 노트의 맨 위 페이지여야 합니다. 해결 작업을 수행한 후 문제 문을 다시 살펴보면 수행한 작업이 문제를 해결했는지 여부를 테스트하고 증명하는 단계를 수행합니다. 이는 작업이 언제 수행되는지 아는 데 중요합니다.
성능이 좋았을 때 어떻게 보였는지 알고 계십니까?
당신이 운이 좋다면, 아무도 모른다. 아무도 숫자가 없었다. 즉, "Office 365 받은 편지함을 가져오는 데 몇 초가 걸렸는가?", 또는 많은 회사에서 일반적인 시나리오인 "경영진이 Lync Online 모임을 가졌을 때 얼마나 걸렸는가?"라는 간단한 질문에 대답할 수 없습니다.
여기서 누락된 것은 성능 기준입니다.
기준은 성능에 대한 컨텍스트를 제공합니다. 회사의 요구 사항에 따라 가끔 기준선을 자주 사용해야 합니다. 대규모 회사인 경우 운영 팀이 온-프레미스 환경에 대한 기준을 이미 사용할 수 있습니다. 예를 들어 월의 첫 번째 월요일에 모든 Exchange 서버를 패치하고 세 번째 월요일에 모든 SharePoint 서버를 패치하는 경우 운영 팀에는 중요한 기능이 작동 중임을 증명하기 위해 패치 후 실행되는 작업 및 시나리오 목록이 포함될 수 있습니다. 예를 들어 받은 편지함을 열고 보내기/받기를 클릭하고 폴더가 업데이트되었는지 확인하거나 SharePoint에서 사이트의 기본 페이지를 탐색하고 엔터프라이즈 Search 페이지로 이동하여 결과를 반환하는 검색을 수행합니다.
애플리케이션이 Office 365 있는 경우 가장 기본적인 기준 중 일부는 네트워크 내의 클라이언트 컴퓨터, 송신 지점 또는 네트워크를 벗어나 Office 365 나가는 지점까지 시간(밀리초)을 측정할 수 있습니다. 다음은 조사하고 기록할 수 있는 몇 가지 유용한 기준입니다.
클라이언트 컴퓨터와 송신 지점(예: 프록시 서버) 사이의 디바이스를 식별합니다.
발생하는 성능 문제에 대한 컨텍스트(IP 주소, 디바이스 유형 등)를 갖도록 디바이스를 알아야 합니다.
프록시 서버는 일반적인 송신 지점이므로 웹 브라우저를 검사 사용할 프록시 서버(있는 경우)를 확인할 수 있습니다.
네트워크를 검색하고 매핑할 수 있는 타사 도구가 있지만 디바이스를 아는 가장 안전한 방법은 네트워크 팀의 구성원에게 문의하는 것입니다.
ISP(인터넷 서비스 공급자)를 식별하고, 연락처 정보를 적어두고, 얼마나 많은 회로에 얼마나 많은 대역폭이 있는지 물어봅니다.
회사 내에서 클라이언트와 송신 지점 사이의 디바이스에 대한 리소스를 식별하거나 네트워킹 문제에 대해 이야기할 긴급 연락처를 식별합니다.
다음은 도구를 사용한 간단한 테스트가 계산할 수 있는 몇 가지 기준입니다.
클라이언트 컴퓨터에서 송신 지점까지의 시간(밀리초)
송신 지점에서 Office 365 시간(밀리초)
검색할 때 Office 365 대한 URL을 확인하는 서버의 세계 위치
ISP의 DNS 확인 속도(밀리초), 패킷 도착 불일치(네트워크 지터), 업로드 및 다운로드 시간(밀리초)
이러한 단계를 수행하는 방법을 잘 모르는 경우 이 문서에서 자세히 살펴보겠습니다.
기준이란?
나쁜 경우 영향을 알 수 있지만 기록 성능 데이터를 모르는 경우 얼마나 나쁜지, 언제 악화되었는지에 대한 컨텍스트를 가질 수 없습니다. 그래서 기준없이, 당신은 퍼즐을 해결하기 위해 핵심 단서를 놓치고있어 : 퍼즐 상자에 그림. 성능 문제 해결에서는 비교 지점이 필요합니다. 간단한 성능 기준을 적용하는 것은 어렵지 않습니다. 운영 팀은 일정에 따라 이러한 작업을 수행할 수 있습니다. 예를 들어 연결이 다음과 같다고 가정해 보겠습니다.
즉, 네트워크 팀과 함께 확인했으며 프록시 서버를 통해 인터넷을 위해 회사를 떠나고 해당 프록시가 클라이언트 컴퓨터가 클라우드로 보내는 모든 요청을 처리한다는 것을 알게 됩니다. 이 경우 모든 중간 디바이스를 나열하는 간소화된 버전의 연결을 그려야 합니다. 이제 클라이언트, 송신 지점(인터넷을 위해 네트워크를 떠나는 위치) 및 Office 365 클라우드 간의 성능을 테스트하는 데 사용할 수 있는 도구를 삽입합니다.
옵션은 성능 데이터를 찾기 위해 필요한 전문 지식의 양 때문에 단순 및 고급 으로 나열됩니다. 네트워크 추적은 PsPing 및 TraceTCP와 같은 명령줄 도구를 실행하는 것과 비교할 때 많은 시간이 소요됩니다. 이 두 명령줄 도구는 Office 365 의해 차단되는 ICMP 패킷을 사용하지 않고 클라이언트 컴퓨터 또는 프록시 서버(액세스 권한이 있는 경우)를 떠나 Office 365 도착하는 데 걸리는 시간을 밀리초 단위로 제공하기 때문에 선택되었습니다. 한 컴퓨터에서 다른 컴퓨터로의 각 개별 홉은 시간 값으로 끝나며 기준선에 적합합니다. 마찬가지로, 이러한 명령줄 도구를 사용하면 명령에 포트 번호를 추가할 수 있습니다. 이는 Office 365 SSL 및 TLS(Secure Sockets Layer and Transport Layer Security)에서 사용하는 포트인 포트 443을 통해 통신하기 때문에 유용합니다. 그러나 다른 타사 도구는 상황에 더 나은 솔루션이 될 수 있습니다. Microsoft는 이러한 도구를 모두 지원하지 않으므로 어떤 이유로 PsPing 및 TraceTCP가 작동하지 않는 경우 Netmon과 같은 도구를 사용하여 네트워크 추적으로 이동합니다.
업무 시간 전에 기준을 사용하고, 사용량이 많은 경우 다시, 몇 시간 후에 다시 기준을 사용할 수 있습니다. 즉, 결국 다음과 같이 보이는 폴더 구조가 있을 수 있습니다.
또한 파일의 명명 규칙도 선택해야 합니다. 다음은 몇 가지 예입니다.
Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal
Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW
Feb_08_2015_2pmEST_PerfBaseline_BADPerf
Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf
이 작업을 수행하는 방법에는 여러 가지가 있지만 dateTime><형식<을 사용하면 테스트에서> 발생하는 작업을 시작하는 것이 좋습니다. 이 문제에 대해 부지런히 하면 나중에 문제를 해결하려고 할 때 많은 도움이 됩니다. 나중에 "2월 8일에 두 개의 추적을 했는데, 하나는 좋은 성능을 보였고 하나는 나쁜 것으로 나타났으므로 비교할 수 있습니다"라고 말할 수 있습니다. 이는 문제 해결에 유용합니다.
기록 기준을 유지할 수 있는 체계적인 방법이 있어야 합니다. 이 예제에서는 간단한 메서드가 3개의 명령줄 출력을 생성하고 결과가 스크린샷으로 수집되었지만 대신 네트워크 캡처 파일이 있을 수 있습니다. 가장 적합한 메서드를 사용합니다. 기록 기준을 저장하고 온라인 서비스 동작이 변경된 것을 확인할 수 있는 지점에서 참조합니다.
파일럿 중에 성능 데이터를 수집하는 이유는 무엇인가요?
Office 365 서비스를 파일럿하는 동안보다 기준을 만드는 것이 더 좋은 시기는 없습니다. 사무실에 수천 명의 사용자, 수십만 명의 사용자가 있거나 5명이 있을 수 있지만 소수의 사용자도 테스트를 수행하여 성능 변동을 측정할 수 있습니다. 대기업의 경우 Office 365 파일럿하는 수백 명의 사용자를 대표하는 샘플은 문제가 발생하기 전에 발생할 수 있는 위치를 알 수 있도록 수천 명까지 바깥쪽으로 프로젝팅할 수 있습니다.
온보딩이 모든 사용자가 동시에 서비스에 이동하고 파일럿이 없다는 것을 의미하는 소규모 회사의 경우 성능 측정을 유지하여 성능이 좋지 않은 작업을 해결해야 할 수 있는 모든 사람에게 표시할 데이터가 있도록 합니다. 예를 들어 갑자기 건물 주변을 돌아다니며 중형 그래픽을 빠르게 업로드할 수 있습니다.
기준을 수집하는 방법
모든 문제 해결 계획의 경우 최소한 다음 사항을 식별해야 합니다.
사용 중인 클라이언트 컴퓨터(컴퓨터 또는 디바이스 유형, IP 주소 및 문제를 일으킨 작업)
클라이언트 컴퓨터가 전 세계에 있는 위치(예: 이 사용자가 네트워크에 대한 VPN, 원격 작업 또는 회사 인트라넷에 있는지 여부)
클라이언트 컴퓨터가 네트워크에서 사용하는 송신 지점(트래픽이 ISP 또는 인터넷의 비즈니스에서 나가는 지점)
네트워크 관리자는 네트워크 레이아웃을 확인할 수 있습니다. 소규모 네트워크에 있는 경우 인터넷에 연결하는 디바이스를 살펴보고 레이아웃에 대한 질문이 있는 경우 ISP에 전화하세요. 참조에 대한 최종 레이아웃의 그래픽을 Create.
이 섹션은 간단한 명령줄 도구 및 메서드 및 고급 도구 옵션으로 구분됩니다. 먼저 간단한 방법을 살펴보겠습니다. 하지만 지금 성능 문제가 있는 경우 고급 메서드로 이동하여 샘플 성능 문제 해결 작업 계획을 시도해야 합니다.
간단한 메서드
이러한 간단한 방법의 목적은 시간에 따라 간단한 성능 기준을 취, 이해 및 적절하게 저장하여 Office 365 성능에 대한 정보를 제공하는 방법을 배우는 것입니다. 다음은 앞에서 보았듯이 간단한 다이어그램입니다.
참고
TraceTCP는 요청이 처리되는 데 걸리는 시간(밀리초) 및 한 컴퓨터에서 다음 컴퓨터로의 연결 수 또는 요청이 대상에 도달하는 데 걸리는 연결을 보여 주는 유용한 도구이기 때문에 이 스크린샷에 포함됩니다. TraceTCP는 홉 중에 사용되는 서버의 이름을 제공할 수도 있습니다. 이 이름은 지원의 Microsoft Office 365 문제 해결사에게 유용할 수 있습니다. > TraceTCP 명령은 다음과 같이 매우 간단할 수 있습니다. >tracetcp.exe outlook.office365.com:443> 명령에 포트 번호를 포함해야 합니다. >TraceTCP 는 무료 다운로드이지만 Wincap에 의존합니다. Wincap은 Netmon에서 사용 및 설치하는 도구입니다. 또한 고급 메서드 섹션에서 Netmon을 사용합니다.
여러 사무실이 있는 경우 각 위치의 클라이언트에서 데이터 집합을 유지해야 합니다. 이 테스트는 대기 시간을 측정합니다. 이 경우 Office 365 요청을 보내는 클라이언트와 요청에 응답하는 Office 365 사이의 시간을 설명하는 숫자 값입니다. 테스트는 클라이언트 컴퓨터의 도메인 내에서 시작되며 네트워크 내부, 송신 지점, 인터넷을 통해 Office 365 왕복을 측정합니다.
이 경우 프록시 서버에서 송신 지점을 처리하는 몇 가지 방법이 있습니다. 1에서 2, 2에서 3까지 추적한 다음, 숫자를 밀리초 단위로 추가하여 네트워크 가장자리에 최종 합계를 가져올 수 있습니다. 또는 Office 365 주소에 대한 프록시를 무시하도록 연결을 구성할 수 있습니다. 방화벽, 역방향 프록시 또는 둘의 일부 조합이 있는 더 큰 네트워크에서는 많은 URL에 대해 트래픽을 전달할 수 있도록 프록시 서버에서 예외를 만들어야 할 수 있습니다. Office 365 사용하는 엔드포인트 목록은 OFFICE 365 URL 및 IP 주소 범위를 참조하세요. 인증 프록시가 있는 경우 먼저 다음에 대한 예외를 테스트합니다.
포트 80 및 443
TCP 및 HTTP
다음 URL에 아웃바운드되는 Connections.
*.microsoftonline.com
*.microsoftonline-p.com
*.sharepoint.com
*.outlook.com
*.lync.com
osub.microsoft.com
모든 사용자는 프록시 간섭이나 인증 없이 이러한 주소에 액세스할 수 있어야 합니다. 더 작은 네트워크에서 웹 브라우저의 프록시 바이패스 목록에 추가해야 합니다.
인터넷 Explorer 프록시 바이패스 목록에 추가하려면 도구>인터넷 옵션>Connections>LAN 설정>고급으로 이동합니다. 또한 고급 탭에서 프록시 서버 및 프록시 서버 포트를 찾을 수 있습니다. LAN에 프록시 서버 사용 확인란을 선택하여 고급 단추에 액세스해야 할 수 있습니다. 로컬 주소에 대한 프록시 서버 우회가 선택되어 있는지 확인합니다. 고급을 선택하면 예외를 입력할 수 있는 텍스트 상자가 표시됩니다. 위에 나열된 와일드카드 URL을 세미콜론으로 구분합니다. 예를 들면 다음과 같습니다.
*.microsoftonline.com; *.sharepoint.com
프록시를 바이패스하면 Office 365 URL에서 직접 ping 또는 PsPing을 사용할 수 있습니다. 다음 단계는 ping outlook.office365.com 테스트하는 것입니다. 또는 PsPing 또는 명령에 포트 번호를 제공할 수 있는 다른 도구를 사용하는 경우 PsPing은 portal.microsoftonline.com:443 대해 평균 왕복 시간을 밀리초 단위로 확인합니다.
왕복 시간(RTT)은 outlook.office365.com 같은 서버로 HTTP 요청을 보내는 데 걸리는 시간을 측정하고 서버가 이를 알고 있음을 인정하는 응답을 다시 가져오는 데 걸리는 시간을 측정하는 숫자 값입니다. 이 약어가 RTT로 표시되는 경우도 있습니다. 비교적 짧은 시간이어야 합니다.
이 테스트를 수행하려면 PSPing 또는 Office 365 의해 차단된 ICMP 패킷을 사용하지 않는 다른 도구를 사용해야 합니다.
PsPing을 사용하여 Office 365 URL에서 직접 전체 왕복 시간을 밀리초 단위로 가져오는 방법
다음 단계를 완료하여 관리자 권한 명령 프롬프트를 실행합니다.
시작을 클릭합니다.
시작 Search 상자에 cmd를 입력한 다음 Ctrl+Shift+Enter를 누릅니다.
사용자 계정 컨트롤 대화 상자가 나타나면 표시되는 작업이 원하는 작업인지 확인한 다음 계속을 클릭합니다.
도구(이 경우 PsPing)가 설치된 폴더로 이동하여 다음 Office 365 URL을 테스트합니다.
psping admin.microsoft.com:443
psping microsoft-my.sharepoint.com:443
psping outlook.office365.com:443
psping www.yammer.com:443
포트 번호는 443이어야 합니다. Office 365 암호화된 채널에서 작동합니다. 포트 번호 없이 PsPing하는 경우 요청이 실패합니다. 짧은 목록을 ping한 후에는 평균 시간(밀리초)을 찾습니다. 이것이 바로 기록하려는 내용입니다!
프록시 바이패스(Proxy Bypass)에 익숙하지 않고 단계별로 작업을 수행하려는 경우 먼저 프록시 서버의 이름을 확인해야 합니다. 인터넷 Explorer 도구>인터넷 옵션>Connections>LAN 설정>고급으로 이동합니다. 고급 탭에는 프록시 서버가 나열됩니다. 다음 작업을 완료하여 명령 프롬프트에서 해당 프록시 서버를 Ping합니다.
프록시 서버를 ping하고 1~2단계의 왕복 값을 밀리초 단위로 받으려면
다음 단계를 완료하여 관리자 권한 명령 프롬프트를 실행합니다.
시작을 클릭합니다.
시작 Search 상자에 cmd를 입력한 다음 Ctrl+Shift+Enter를 누릅니다.
사용자 계정 컨트롤 대화 상자가 나타나면 표시되는 작업이 원하는 작업인지 확인한 다음 계속을 클릭합니다.
브라우저에서 사용하는 프록시 서버의 이름 또는 프록시> 서버의 IP 주소를 ping<으로 입력한 다음 Enter 키를 누릅니다. PsPing 또는 다른 도구가 설치된 경우 해당 도구를 대신 사용하도록 선택할 수 있습니다.
명령은 다음 예제와 같을 수 있습니다.
ping ourproxy.ourdomain.industry.business.com
ping 155.55.121.55
ping ourproxy
psping ourproxy.ourdomain.industry.business.com:80
psping 155.55.121.55:80
psping ourproxy:80
- 추적이 테스트 패킷 전송을 중지하면 평균(밀리초)을 나열하는 작은 요약이 표시되며, 이 값은 다음과 같습니다. 프롬프트의 스크린샷을 만들고 명명 규칙을 사용하여 저장합니다. 이 시점에서 다이어그램을 값으로 채우는 데도 도움이 될 수 있습니다.
이른 아침에 추적을 수행했고 클라이언트가 프록시(또는 인터넷으로 나가는 송신 서버)에 빠르게 연결할 수 있습니다. 이 경우 숫자는 다음과 같을 수 있습니다.
클라이언트 컴퓨터가 프록시(또는 송신) 서버에 액세스할 수 있는 몇 안 되는 선택 항목 중 하나인 경우 해당 컴퓨터에 원격으로 연결하고 명령 프롬프트를 PsPing에서 Office 365 URL로 실행하여 테스트의 다음 단계를 실행할 수 있습니다. 해당 컴퓨터에 액세스할 수 없는 경우 네트워크 리소스에 문의하여 다음 구간에 대한 도움을 받고 정확한 숫자를 가져올 수 있습니다. 이것이 불가능한 경우 문제의 Office 365 URL에 대해 PsPing을 가져와서 프록시 서버에 대한 PsPing 또는 Ping 시간과 비교합니다.
예를 들어 클라이언트에서 Office 365 URL까지 51.84밀리초가 있고 클라이언트에서 프록시(또는 송신 지점)까지 2.8밀리초가 있는 경우 송신에서 Office 365 49.04밀리초가 있습니다. 마찬가지로, 하루의 높이 동안 클라이언트에서 프록시로 12.25밀리초, 클라이언트에서 Office 365 URL로 62.01밀리초의 PsPing이 있는 경우 Office 365 URL로의 프록시 송신에 대한 평균 값은 49.76밀리초입니다.
문제 해결 측면에서 이러한 기준을 유지하는 것만으로도 흥미로운 것을 발견할 수 있습니다. 예를 들어 일반적으로 프록시 또는 송신 지점에서 Office 365 URL까지 약 40밀리초에서 59밀리초의 대기 시간이 있는 경우 클라이언트에서 프록시 또는 송신 지점 대기 시간이 약 3밀리초에서 7밀리초(해당 시간 동안 표시되는 네트워크 트래픽 양에 따라 다름)가 있는 경우 프록시 또는 송신 기준선에 대한 마지막 3개 클라이언트가 대기 시간이 45밀리초입니다.
고급 메서드
Office 365 인터넷 요청에서 발생하는 일을 실제로 알고 싶다면 네트워크 추적에 익숙해져야 합니다. 이러한 추적, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, 개발자 대시보드 도구 또는 기타 추적에 원하는 도구는 해당 도구가 네트워크 트래픽을 캡처하고 필터링할 수 있는 한 중요하지 않습니다. 이 섹션에서는 이러한 도구 중 하나 이상을 실행하여 문제를 보다 완벽하게 파악하는 것이 유익하다는 것을 알 수 있습니다. 테스트할 때 이러한 도구 중 일부는 그 자체로 프록시 역할을 합니다. Office 365 대한 성능 문제 해결 계획과 함께 제공되는 도구에는 Netmon 3.4, HTTPWatch 또는 WireShark가 포함됩니다.
성능 기준을 사용하는 것은 이 방법의 간단한 부분이며, 대부분의 단계는 성능 문제를 해결할 때와 동일합니다. 성능에 대한 기준을 만드는 고급 방법을 사용하려면 네트워크 추적을 가져와서 저장해야 합니다. 이 문서의 예제 대부분은 SharePoint를 사용하지만 테스트 및 레코드를 구독하는 Office 365 서비스에서 일반적인 작업 목록을 개발해야 합니다. 기준 예제는 다음과 같습니다.
SPO에 대한 기준 목록 - ** 1단계: ** SPO 웹 사이트의 홈페이지를 찾아 네트워크 추적을 수행합니다. 추적을 저장합니다.
SPO에 대한 기준 목록 - 2단계: 엔터프라이즈 Search 통해 용어(예: 회사 이름)에 대한 Search 네트워크 추적을 수행합니다. 추적을 저장합니다.
SPO에 대한 기준 목록 - 3단계: SharePoint 문서 라이브러리에 큰 파일을 업로드하고 네트워크 추적을 수행합니다. 추적을 저장합니다.
SPO 기준 목록 - 4단계: OneDrive 웹 사이트의 홈페이지를 찾아 네트워크 추적을 수행합니다. 추적을 저장합니다.
이 목록에는 사용자가 SharePoint에 대해 수행하는 가장 중요한 일반적인 작업이 포함되어야 합니다. OneDrive로 가는 것을 추적하기 위한 마지막 단계는 SharePoint 홈페이지의 로드(회사에서 사용자 지정하는 경우가 많음)와 거의 사용자 지정되지 않는 OneDrive 홈페이지 간의 비교를 빌드합니다. 이 테스트는 느리게 로드되는 SharePoint 사이트에 관한 기본 테스트입니다. 이러한 차이점에 대한 레코드를 테스트에 작성할 수 있습니다.
성능 문제의 중간에 있는 경우 대부분의 단계는 기준을 수행할 때와 동일합니다. 네트워크 추적은 중요하므로 다음으로 중요한 추적을 수행하는 방법을 처리합니다.
성능 문제를 해결하려면 성능 문제가 발생한 시점에 추적을 수행해야 합니다. 로그를 수집하는 데 사용할 수 있는 적절한 도구가 있어야 하며, 가능한 최상의 정보를 수집하기 위해 수행할 문제 해결 작업 목록인 작업 계획이 필요합니다. 가장 먼저 해야 할 일은 타이밍을 반영하는 폴더에 파일을 저장할 수 있도록 테스트 날짜와 시간을 기록하는 것입니다. 다음으로, 문제 단계 자체로 범위를 좁힐 수 있습니다. 테스트에 사용할 정확한 단계입니다. 기본 사항을 잊지 마세요. Outlook에만 문제가 있는 경우 문제 동작이 하나의 Office 365 서비스에서만 발생한다는 것을 기록해야 합니다. 이 문제의 scope 축소하면 resolve 수 있는 항목에 집중하는 데 도움이 됩니다.