초기 계획 및 성능 기록을 사용하여 Office 365 성능 조정Office 365 performance tuning using baselines and performance history

연결의 대략적인 기준을 설정할 수 있도록 Office 365 비즈니스 간의 연결 성능을 확인할 수 있는 몇 가지 간단한 방법이 있습니다.There are some simple ways to check the connection performance between Office 365 and your business that will let you establish a rough baseline of your connectivity. 클라이언트 컴퓨터 연결의 성능 기록을 파악하면 새로운 문제를 조기 검색하고, 식별하고, 예측하는 데 도움이 될 수 있습니다.Knowing the performance history of your client computer connections can help you detect emerging issues early, identify, and predict problems.

성능 문제를 사용하는 데 사용되지 않는 경우 이 문서는 성능 문제가 아닌 성능 문제인지 어떻게 알 수 있나요? 같은 몇 가지 일반적인 질문을 고려하도록 Office 365 있습니다.If you're not used to working on performance issues, this article is designed to help you consider some common questions, like How do you know the problem you're seeing is a performance issue and not an Office 365 service incident? 장기적인 양호한 성능을 계획할 수 있는 방법How can you plan for good performance, long term? 성능을 어떻게 유지할 수 있나요?How can you keep an eye on performance? 팀 또는 클라이언트가 클라이언트를 사용하는 동안 성능이 Office 365 이러한 질문이 궁금한 경우 계속 읽어 봐야 합니다.If your team or clients are seeing slow performance while using Office 365, and you wonder about any of these questions, read on.


현재 클라이언트와 클라이언트 간의 성능 Office 365 문제가 있나요?Have a performance issue between your client and Office 365 right now? 에 대한 성능 문제 해결 계획에 설명된 단계를 Office 365.Follow the steps outlined in the Performance troubleshooting plan for Office 365.

성능에 대해 알아야 할 Office 365 있습니다.Something you should know about Office 365 performance

Office 365 자동화가 아니라 실제 사용자에 의해서도 꾸준히 모니터링되는 대용량 전용 Microsoft 네트워크 내부에 있습니다.Office 365 lives inside a high-capacity, dedicated Microsoft network that is steadily monitored not just by automation, but by real people. Office 365 클라우드를 유지 관리하는 역할의 일부로 성능 조정을 구축하고 가능한 경우 간소화합니다.Part of the role of maintaining the Office 365 cloud is building-in performance tuning and streamlining where it's possible. Office 365 클라우드의 클라이언트는 인터넷을 통해 연결해야 하기 때문에 여러 서비스에서 성능을 세밀하게 조정하기 위한 지속적인 Office 365 있습니다.Since clients of the Office 365 cloud have to connect across the Internet, there is a continuous effort to fine-tune the performance across Office 365 services too. 성능 향상은 클라우드에서 절대 중지되지 않을 것이고 클라우드를 건강하고 빠르게 유지하는 데 많은 누적된 경험이 있습니다.Performance improvements never really stop in the cloud, and there is a lot of accumulated experience with keeping the cloud healthy and quick. 위치에서 다른 위치로 연결되는 성능 문제가 Office 365 지원 사례를 시작하고 대기하지 않는 것이 좋습니다.Should you experience a performance issue connecting from your location to Office 365, it's best not to start with, and wait on, a Support case. 대신 '내부 내부'에서 문제 조사를 시작해야 합니다.Instead, you should begin investigating the problem from 'the inside out'. 즉, 네트워크 내부에서 시작하여 네트워크 내부에서 Office 365.That is, start inside of your network, and work your way out to Office 365. 지원 센터에서 사례를 Office 365 전에 데이터를 수집하고 문제를 탐색하고 해결할 수 있는 조치를 취할 수 있습니다.Before you open a case with Office 365 Support, you can gather data and take actions that will explore, and may resolve, your problem.


용량 계획 및 제한에 Office 365.Be aware of capacity planning and limits in Office 365. 이 정보는 성능 문제를 해결하려고 할 때 곡선을 앞서나가게 됩니다.That information will put you ahead of the curve when trying to resolve a performance issue. 다음은 서비스 설명 및 Microsoft 365 Office 365 링크입니다.Here's a link to the Microsoft 365 and Office 365 service descriptions. 이 허브는 중앙 허브로, 여기에서 Office 365 서비스 설명으로 연결되는 링크가 있습니다.This is a central hub, and all the services offered by Office 365 have a link that goes to their own Service Descriptions from here. 즉, SharePoint Online에 대한 표준 제한을 보려면 SharePoint Online 서비스 설명을 클릭하고 해당 SharePoint 온라인 제한 섹션을 찾습니다.That means, should you need to see the standard limits for SharePoint Online, for example, you would click SharePoint Online Service Description and locate its SharePoint Online Limits section.

성능이 미끄러진 규모라고 이해하여 문제 해결에 들어가야 합니다. 이상화된 가치를 달성하고 영구적으로 유지 관리하는 것이 아니라 문제를 해결해야 합니다. 이 경우 많은 수의 사용자를 대입하거나 대규모 데이터 마이그레이션을 수행하는 등 대역폭이 높은 작업이 가끔 수행될 수 있으므로 성능에 미치는 영향에 대한 계획을 세우면 됩니다.Make sure you go into your troubleshooting with the understanding that performance is a sliding scale, it's not about achieving an idealized value and maintaining it permanently (if you believe this is so, then occasional high-bandwidth tasks like on-boarding a large number of users, or doing large data migrations will be very stressful -- so do plan for performance impacts then). 성능 목표를 대략적으로 구할 수 있지만 성능에 많은 변수가 작용하므로 성능이 다릅니다.You can, and should, have a rough idea of your performance targets, but a lot of variables play into performance, therefore, performance varies. 이는 성능의 특성입니다.That's the nature of performance.

성능 문제 해결은 특정 목표를 달성하고 이러한 숫자를 무기한 유지 관리하는 것이 아니라 모든 변수를 통해 기존 활동을 개선하는 것입니다.Performance troubleshooting isn't about meeting specific goals and maintaining those numbers indefinitely, it's about improving existing activities, given all the variables.

성능 문제가 어떻게 보이나요?Okay, what does a performance problem look like?

먼저 발생하는 문제가 서비스 인시던트가 아닌 성능 문제인지 확인해야 합니다.First, you need to make sure that what you are experiencing is indeed a performance issue and not a service incident. 성능 문제는 2016년 8월의 서비스 인시던트와 Office 365.A performance problem is different from a service incident in Office 365. 이들을 분리하는 방법에는 다음이 있습니다.Here's how to tell them apart.

서비스 Office 365 문제가 있는 경우 서비스 인시던트입니다.If the Office 365 service is having issues, that's a service incident. Microsoft 365 관리 센터의 현재 상태 아래에 빨간색 또는 노란색 아이콘이 표시되고 클라이언트 컴퓨터에 연결되는 클라이언트 컴퓨터에서 성능이 Office 365.You will see red or yellow icons under Current health in the Microsoft 365 admin center, you may also notice slow performance on client computers connecting to Office 365. 예를 들어 현재 상태 보고서에 빨간색 아이콘이 표시되어 있는 경우 Exchange 옆에 조사 중이 표시될 경우 조직 내 사용자로부터 조직 내 사용자로부터 전화를 여러 번 받으면 해당 사서함을 사용하는 클라이언트 사서함이 잘못된 Exchange Online 수 있습니다.For example, if Current health reports a red icon and you see Investigating beside Exchange, you might then also receive a bunch of calls from people in your organization who complain that client mailboxes that use Exchange Online are performing badly. 이 경우 서비스 내에서 Exchange Online 성능에 문제가 있는 것으로 가정하는 것이 합리적입니다.In that case, it's reasonable to assume that your Exchange Online performance just became a victim of issues within the Service.

서비스 Office 365 표시하는 작업을 제외한 모든 워크로드가 녹색으로 Exchange 상태 대시보드입니다.

이제 Office 365 관리자인 사용자는 현재 상태와 세부 정보 및 기록 보기를 자주 확인하여 시스템에서 수행하는 유지 관리에 대한 최신 정보를 유지 관리해야 합니다.At this point, you, the Office 365 admin, should check Current health and then View details and history, frequently, to keep up to date on maintenance we perform on the system. 현재 상태 대시보드는 서비스의 변경 내용 및 문제에 대해 업데이트하기 위해 만들어졌다.The Current health dashboard was made to update you about changes to, and problems in, the service. 상태 기록, 관리자에게 기록된 메모 및 설명은 영향을 측정하고 지속적인 업무에 대해 계속 게시할 수 있도록 도와 줄 수 있습니다.The notes and explanations written to health history, admin to admin, are there to help you gauge your impact, and to keep you posted about ongoing work.

Office 365 서비스가 복원된 이유와 Exchange Online 설명하는 Exchange Online 상태 대시보드의 그림입니다.

인시던트로 인해 성능이 저하될 수 있는 경우에도 성능 문제는 서비스 인시던트가 아닙니다.A performance issue isn't a service incident, even though incidents can cause slow performance. 성능 문제는 다음과 같습니다.A performance issue looks like this:

  • 성능 문제는 관리 센터에서 서비스에 대해 보고하는 상태와 상관없이 발생합니다.A performance issue occurs no matter what the admin center Current health is reporting for the service.

  • 비교적 원활한 동작은 완료하는 데 시간이 오래 걸리거나 완료되지 않습니다.A behavior that used to be relatively seamless takes a long time to complete or never completes.

  • 문제도 복제할 수 있습니다. 또는 적어도 일련의 올바른 단계를 수행하면 문제가 발생하게 될 수 있습니다.You can replicate the problem too, or, at least, you know it will happen if you do the right series of steps.

  • 문제가 간헐적으로 발생하면 오전 10시까지 안정적으로 액세스할 수 없는 사용자로부터의 전화가 걸려오고 Office 365 정오를 전후로 통화가 종료되는 패턴이 있습니다.If the problem is intermittent, there is still a pattern, for example, you know that by 10:00 AM you will have calls from users who can't reliably access Office 365, and that the calls will die down around noon.

이는 익숙한 것일 수 있습니다. 너무 익숙할 수 있습니다.This probably sounds familiar; maybe too familiar. 성능 문제가 발생하면 질문이 "다음에 어떻게 해야 나요?"가 됩니다.Once you know it's a performance problem, the question becomes, "What do you do next?" 이 문서의 나머지부분은 정확히 이를 확인하는 데 도움이 됩니다.The rest of this article helps you determine exactly that.

성능 문제를 정의하고 테스트하는 방법How to define and test the performance problem

성능 문제는 시간이 지날 때 종종 발생하기 때문에 실제 문제를 정의하기 어려울 수 있습니다.Performance issues often emerge over time, so it can be challenging to define the actual problem. 문제 컨텍스트에 대한 좋은 문제 설명과 좋은 생각을 만들어야 합니다. 그런 다음 반복 가능한 테스트 단계를 통해 문제를 해결해야 합니다.You need to create a good problem statement and a good idea of issue context, and then you need to repeatable testing steps to win the day. 그렇지 않으면 자신의 잘못을 통해 손실될 수 있습니다.Otherwise, through no fault of your own, you may be lost. 이유Why? 충분한 정보를 제공하지 않는 문제 설명의 몇 가지 예는 다음과 같습니다.Well, here are some examples of problems statements that don't provide enough information:

  • 받은 편지함에서 내 일정으로 전환하는 중에는 눈에 띄지 않았던 것이지만 이제는 커피를 마신 것입니다.Switching from my Inbox to my Calendar used to be something I didn't notice, and now it's a coffee-break. 사용할 수 있는 것 같은 역할을 할 수 있나요?Can you make it act like it used to?

  • 내 파일을 온라인 SharePoint 업로드하는 데는 이행이 든 것입니다.Uploading my files to SharePoint Online is taking forever. 오후에는 느리지만 그 외의 경우 속도가 빠릅니다.Why is it slow in the afternoon, but any other time, it's fast? 빠를 수 없는가요?Can't it just be fast?

위의 문제 진술에 의해 몇 가지 큰 문제가 발생했습니다.There are several large challenges posed by the problem statements above. 특히, 처리해야 할 모호한 많음이 있습니다.Specifically, there are a lot of ambiguities to deal with. 예를 들어:for example:

  • 노트북에서 받은 편지함과 일정을 전환하는 방식은 불분명합니다.It's unclear how switching between Inbox and Calendar used to act on the laptop.

  • 사용자가 "빠를 수 없습니다."라고 말하면 "빠르면"이란?When the user says, "Can't it just be fast", what's "fast"?

  • How long is "forever"?How long is "forever"? 몇 초 또는 몇 분이면 사용자가 점심 식사로 이동하여 사용자가 돌아오고 10분 후에 완료될 수 있나요?Is that several seconds, or minutes, or could the user go to lunch and it would finish up ten minutes after the user got back?

이러한 모든 문제는 관리자와 문제 해결사에서 이러한 문제 설명의 많은 세부 정보를 인식할 수 없다고 고려하지 않고 있습니다.All of this is without considering that the admin and troubleshooter can't be aware of many details from problem statements like these. 예를 들어 문제가 발생하기 시작한 경우 사용자가 집에서 작업하며 홈 네트워크에서만 느린 전환을 볼 수 있습니다. 사용자가 로컬 클라이언트에서 여러 다른 RAM을 많이 사용하는 응용 프로그램을 실행해야 합니다. 또는 사용자가 이전 운영 체제를 실행 중이거나 최신 업데이트를 실행하지 않은 경우For example, when the problem started happening; That the user works from home and only ever sees slow switching while on a home network; That the user must run several other RAM intensive applications on the local client, or the user is running an older operating system or hasn't run recent updates.

사용자가 성능 문제를 보고하면 수집할 정보가 많이 있습니다.When users report a performance problem, there's a lot of information to collect. 이 정보를 수집하는 것은 문제의 스크래핑 또는 조사라는 프로세스의 일부입니다.Collecting this information is part of a process called scoping the issue, or investigating it. 다음은 성능 문제와 관련한 정보를 수집하는 데 사용할 수 있는 기본 선택 목록입니다.The following is a basic scoping list you can use to collect information about your performance issue. 이 목록은 전체 목록이 아니며, 다음 중 하나를 시작할 수 있는 장소입니다.This list is not exhaustive, but it's a place to start one of your own:

  • 어떤 날짜에 문제가 발생하고 하루 중 어떤 시간이 발생했습니까?On what date did the issue happen, and around what time of day or night?

  • 사용 중이던 클라이언트 컴퓨터의 종류와 비즈니스 네트워크(VPN, 유선, 무선)에 어떻게 연결하나요?What kind of client computer were you using, and how does it connect to the business network (VPN, Wired, Wireless)?

  • 원격으로 작업 중이거나 사무실에 있나요?Were you working remotely or were you in the office?

  • 다른 컴퓨터에서 동일한 작업을 시도하고 동일한 동작을 표시했습니까?Did you try the same actions on another computer and see the same behavior?

  • 문제를 해결하고 있는 작업을 작성할 수 있도록 단계를 진행합니다.Walk through the steps that are giving you the trouble so that you can write the actions you take down.

  • 성능은 몇 초 또는 몇 분 정도 느리나요?How slow in seconds or minutes is the performance?

  • 전 세계 어디에 있나요?Where in the world are you located?

이러한 질문 중 일부는 다른 질문보다 더 명확합니다.Some of these questions are more obvious than others. 대부분의 모든 사람은 문제 해결사에서 문제를 재현하는 정확한 단계가 필요하다는 것을 이해합니다.Most everyone will understand a troubleshooter needs the exact steps to reproduce the issue. 결국 다른 문제를 기록할 수 있는 방법과 문제가 해결된 경우 어떻게 테스트할 수 있나요?After all, how else can you record what's wrong, and how else can you test if the issue is fixed? "문제가 어떤 날짜와 시간이 표시 했나요?", "현재 위치는 어디인가요?"처럼 명확하지 않은 정보를 함께 사용할 수 있습니다.Less obvious are things like "What date and time did you see the issue?", and "Where in the world are you located?", information that can be used in tandem. 사용자가 근무한 시간에 따라 몇 시간의 시간 차이로 회사 네트워크의 일부에서 유지 관리가 이미 진행 중일 수 있습니다.Depending on when the user was working, a few hours of time difference may mean maintenance is already underway on parts of your company's network. 예를 들어 회사에 SharePoint Online 및 SharePoint Server 2013 인스턴스의 검색 인덱스를 쿼리할 수 있는 하이브리드 SharePoint Search와 같은 하이브리드 구현이 있는 경우, 업데이트가 사내 팜에서 진행될 수 있습니다.If, for example, your company has a hybrid implementation, like a hybrid SharePoint Search, which can query search indexes in both SharePoint Online and an On-premises SharePoint Server 2013 instance, updates may be underway in the on-premises farm. 회사가 모두 클라우드에 있는 경우 시스템 유지 관리에는 네트워크 하드웨어 추가 또는 제거, 회사 전체의 업데이트 롤아웃 또는 DNS 또는 기타 핵심 인프라 변경이 포함됩니다.If your company is all in the cloud, system maintenance may include adding or removing network hardware, rolling out updates that are company-wide, or making changes to DNS, or other core infrastructure.

성능 문제를 해결할 때 범죄 현장과 약간 같은 경우 증거에서 결론을 도출하려면 정확하고 관찰적이 필요합니다.When you're troubleshooting a performance problem, it's a bit like a crime scene, you need to be precise and observant to draw any conclusions from the evidence. 이를 위해서는 증거를 수집하여 좋은 문제 설명을 얻을 수 있어야 합니다.In order to do this, you must get a good problem statement by gathering evidence. 여기에는 컴퓨터의 컨텍스트, 사용자의 컨텍스트, 문제가 시작된 때 및 성능 문제를 노출한 정확한 단계가 포함되어야 합니다.It should include the computer's context, the user's context, when the problem began, and the exact steps that exposed the performance issue. 이 문제 설명은 메모에서 맨 위에 있는 페이지로 유지해야 합니다.This problem statement should be, and stay, the topmost page in your notes. 해결 방법을 수행한 후 문제 설명을 다시 확인하여 조치를 수행하여 문제를 해결한 것인지 테스트하고 증명하는 단계를 수행하게 됩니다.By walking through the problem statement again after you work on the resolution, you are taking the steps to test and prove whether the actions you take have resolved the issue. 이 설정은 작업의 완료 시를 아는 데 중요합니다.This is critical to knowing when your work, there, is done.

성능이 양호한 경우의 성능을 어떻게 볼 수 있나요?Do you know how performance used to look when it was good?

문제가 없는 경우 아무도 알 수 없습니다.If you're unlucky, nobody knows. 누구도 숫자를 들이지 못합니다.Nobody had numbers. 즉, 아무도 "Office 365에서 받은 편지함을 가져오는 데 몇 초 정도 걸릴까요?"라는 간단한 질문이나 "임원이 Lync Online 모임을 할 때 얼마나 오래 사용했나요?"라는 간단한 질문에 대답할 수 없습니다. 이는 많은 회사에서 흔히 볼 수 있는 시나리오입니다.That means nobody can answer the simple question "About how many seconds did it used to take to bring up an Inbox in Office 365?", or "How long did it used to take when the Executives had a Lync Online meeting?", which is a common scenario for many companies.

여기서 누락된 것은 성능 기준입니다.What's missing here is a performance baseline.

기준은 성능에 대한 컨텍스트를 제공합니다.Baselines give you a context for your performance. 회사의 요구에 따라 종종 기준을 세우는 것이 좋습니다.You should take a baseline occasionally to frequently, depending on the needs of your company. 대기업의 경우 Operations 팀이 이미 사내 환경에 대한 기준을 사용할 수 있습니다.If you are a larger company, your Operations team may take baselines for your on-premises environment already. 예를 들어 첫 번째 월요일에 모든 Exchange 서버를 패치하고 세 번째 월요일에 모든 SharePoint 서버를 패치하는 경우 작업 팀에는 패치 후 실행되는 작업 및 시나리오 목록이 표시되어 중요한 기능이 작동하고 있는 것을 증명할 수 있습니다.For example, if you patch all the Exchange servers on the first Monday of the month, and all your SharePoint servers on the third Monday, your Operations team probably has a list of tasks and scenarios it runs post-patching, to prove that critical functions are operational. 예를 들어 받은 편지함을 열고 보내기/받기를 클릭한 다음 폴더가 업데이트되어 있는지 확인하거나SharePoint 사이트의 기본 페이지를 찾아 엔터프라이즈 검색 페이지로 이동한 다음 결과를 반환하는 검색을 수행하도록 할 수 있습니다.For example, opening the Inbox, clicking Send/Receive, and making sure the folders update, or, in SharePoint, browsing the main page of the site, going into the enterprise Search page, and doing a search that returns results.

응용 프로그램이 Office 365 경우 가장 기본적인 기준 중 일부는 네트워크 내부의 클라이언트 컴퓨터, 발신 지점 또는 네트워크를 떠나 네트워크로 나가는 지점까지의 시간을 밀리초로 측정할 수 Office 365.If your applications are in Office 365, some of the most fundamental baselines you can take measure the time (in milliseconds) from a client computer inside your network, to an egress point, or the point where you leave your network and go out to Office 365. 다음은 조사하고 기록할 수 있는 몇 가지 유용한 기준입니다.Here are some helpful baselines that you can investigate and record:

  • 클라이언트 컴퓨터와 시작 지점 간의 장치(예: 프록시 서버)를 식별합니다.Identify the devices between your client computer and your egress point, for example, your proxy server.

    • 발생하는 성능 문제에 대한 컨텍스트(IP 주소, 장치 유형, et cetera)가 있도록 디바이스를 알아야 합니다.You need to know your devices so that you have context (IP addresses, type of device, et cetera) for performance problems that arise.

    • 프록시 서버는 일반적인 전송 지점이기 때문에 웹 브라우저에서 사용할 프록시 서버(있는 경우)를 확인할 수 있습니다.Proxy servers are common egress points, so you can check your web browser to see what proxy server it is set to use, if any.

    • 네트워크를 검색하고 매핑할 수 있는 타사 도구가 있지만 장치를 아는 가장 안전한 방법은 네트워크 팀 구성원에게 요청하는 것입니다.There are third party tools that can discover and map your network, but the safest way to know your devices is to ask a member of your network team.

  • ISP(인터넷 서비스 공급자)를 식별하고, 연락처 정보를 기록하고, 대역폭의 수를 묻습니다.Identify your Internet service provider (ISP), write down their contact information, and ask how many circuits how much bandwidth you have.

  • 회사 내에서 클라이언트와 시작 지점 사이의 장치에 대한 리소스를 식별하거나 네트워킹 문제에 대해 논의할 긴급 연락처를 식별합니다.Inside your company, identify resources for the devices between your client and the egress point, or identify an emergency contact to talk to about networking issues.

다음은 도구를 사용하여 간단한 테스트를 통해 계산할 수 있는 몇 가지 기준입니다.Here are some baselines that simple testing with tools can calculate for you:

  • 클라이언트 컴퓨터에서 시작 지점까지의 시간(밀리초)입니다.Time from your client computer to your egress point in milliseconds

  • 시작 지점에서 Office 365 시간(밀리초)입니다.Time from your egress point to Office 365 in milliseconds

  • 검색할 때 서버의 URL을 Office 365 위치Location in the world of the server that resolves the URLS for Office 365 when you browse

  • ISP의 DNS 확인 속도(밀리초), 패킷 도착 시 불일치(네트워크 지터), 업로드 및 다운로드 시간(밀리초)The speed of your ISP's DNS resolution in milliseconds, inconsistencies in packet arrival (network jitter), upload and download times in milliseconds

이러한 단계를 수행하기에 익숙하지 않은 경우 이 문서에서 자세히 설명할 것입니다.If you're unfamiliar with how to carry out these steps, we'll go into more detail in this article.

기준이란?What is a baseline?

문제가 있을 때의 영향을 알 수 있지만 기록 성능 데이터를 모르는 경우 악의적인 상황과 그 때에 대한 컨텍스트를 사용할 수 없습니다.You'll know the impact when it goes bad, but if you don't know your historical performance data, it's not possible to have a context for how bad it may have become, and when. 따라서 기본이 없는 경우 퍼즐을 해결하기 위한 키 단서( 퍼즐 상자의 그림)가 없습니다.So without a baseline, you're missing the key clue to solve the puzzle: the picture on the puzzle box. 성능 문제 해결에서 비교 지점이 필요합니다.In performance troubleshooting, you need a point of comparison . 간단한 성능 기준은 사용하기가 어렵습니다.Simple performance baselines aren't difficult to take. 작업 팀에서는 이러한 작업을 일정에 따라 수행해야 할 수 있습니다.Your Operations team can be tasked with carrying these out on a schedule. 예를 들어 연결의 모양은 다음과 같습니다.For example, let's say your connection looks like this:

클라이언트, 프록시 및 클라우드를 보여 Office 365 네트워크 그래픽입니다.

즉, 네트워크 팀에 확인한 결과 프록시 서버를 통해 회사를 퇴사하고 해당 프록시는 클라이언트 컴퓨터가 클라우드로 보내는 모든 요청을 처리합니다.That means you've checked with your network team and found out that you leave your company for the Internet through a proxy server, and that proxy handles all the requests your client computer sends to the cloud. 이 경우 모든 중간 장치를 나열하는 간소화된 버전의 연결을 그려야 합니다.In this case, you should draw a simplified version of your connection that lists all the intervening devices. 이제 클라이언트, 나가는 지점(인터넷을 위해 네트워크를 떠날 위치) 및 클라우드와 클라우드 간의 성능을 테스트하는 데 사용할 수 있는 Office 365 삽입합니다.Now, insert tools that you can use to test the performance between the client, the egress point (where you leave your network for the Internet), and the Office 365 cloud.

클라이언트, 프록시 및 클라우드가 있는 기본 네트워크와 PSPing, TraceTCP 및 네트워크 추적을 제안하는 도구가 있습니다.

성능 데이터를 찾는 데 필요한 전문 지식이 있기 때문에 옵션이 단순 및 고급으로 나열됩니다.The options are listed as Simple and Advanced because of the amount of expertise you need in order to find the performance data. 네트워크 추적은 PsPing 및 TraceTCP와 같은 명령줄 도구를 실행하는 데 비해 시간이 많이 걸릴 수 있습니다.A network trace will take a lot of time, compared to running command-line tools like PsPing and TraceTCP. 이러한 두 명령줄 도구는 Office 365 의해 차단되는 ICMP 패킷을 사용하지 않는 것이고 클라이언트 컴퓨터 또는 프록시 서버(액세스 권한이 있는 경우)에서 퇴장하고 ICMP에 도착하는 데 걸리는 시간(밀리초)을 제공하기 때문에 Office 365.These two command-line tools were chosen because they don't use ICMP packets, which will be blocked by Office 365, and because they give the time in milliseconds that it takes to leave the client computer, or proxy server (if you have access) and arrive at Office 365. 한 컴퓨터에서 다른 컴퓨터로의 각 개별 홉은 시간 값으로 끝나며 이는 기준에 좋습니다.Each individual hop from one computer to another will end up with a time value, and that's great for baselines! 중요한 점은 이러한 명령줄 도구를 사용하여 명령에 포트 번호를 추가할 수 있습니다. 이 기능은 Office 365 및 SSL 및 TLS(전송 계층 보안)에서 사용하는 포트인 Office 365 Secure Sockets Layer 통신하기 때문에 유용합니다.Just as importantly, these command-line tools allow you to add a port number onto the command, this is useful because Office 365 communicates over port 443, which is the port used by Secure Sockets Layer and Transport Layer Security (SSL and TLS). 그러나 다른 타사 도구는 상황에 대한 더 나은 솔루션일 수 있습니다.However, other third-party tools may be better solutions for your situation. Microsoft는 이러한 도구를 모두 지원하지 않습니다. 따라서 어떤 이유로 PsPing 및 TraceTCP를 사용할 수 없는 경우 Netmon과 같은 도구를 사용하여 네트워크 추적으로 이동하세요.Microsoft doesn't support all of these tools, so if, for some reason, you can't get PsPing and TraceTCP working, move on to a network trace with a tool like Netmon.

업무 시간 전에 기준을 다시 세우고, 과도하게 사용하는 동안에는 다시 한 번 시간을 사용할 수 있습니다.You can take a baseline before business hours, again during heavy use, and then again after hours. 즉, 다음과 같은 폴더 구조가 끝에 있을 수 있습니다.This means you may have a folder structure that looks a bit like this in the end:

성능 데이터를 폴더로 구성하는 방법을 제시하는 그래픽

파일 이름 규칙도 선택해야 합니다.You should also pick a naming convention your files. 다음은 몇 가지 예입니다.Here are some examples:

  • Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_NormalFeb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

  • Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOWJan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • Feb_08_2015_2pmEST_PerfBaseline_BADPerfFeb_08_2015_2pmEST_PerfBaseline_BADPerf

  • Feb_08_2015_8-30amEST_PerfBaseline_GoodPerfFeb_08_2015_8-30amEST_PerfBaseline_GoodPerf

다양한 방법으로 이 작업을 시작할 수 있지만 형식을 사용하는 <dateTime><what's happening in the test> 것이 좋습니다.There are lots of different ways to do this, but using the format <dateTime><what's happening in the test> is a good place to start. 이에 대해 부지런히 생각하면 나중에 문제를 해결하려고 할 때 많은 도움이 됩니다.Being diligent about this will help a lot when you are trying to troubleshoot issues later. 나중에 "2월 8일 두 번의 추적을 진행했습니다. 하나는 좋은 성능을 보여 주며 다른 하나는 좋지 않은 결과를 나타났기 때문에 비교할 수 있습니다."라고 말할 수 있습니다.Later, you'll be able to say "I took two traces on February 8th, one showed good performance and one showed bad, so we can compare them". 이 방법은 문제 해결에 매우 유용합니다.This is extremely helpful for troubleshooting.

기록 기준을 유지할 수 있는 체계적인 방법이 필요합니다.You need to have an organized way to keep your historical baselines. 이 예제에서는 간단한 메서드로 세 개의 명령줄 출력이 생성되고 결과가 스크린샷으로 수집되지만 대신 네트워크 캡처 파일이 있을 수 있습니다.In this example, the simple methods produced three command line outputs and the results were collected as screen shots, but you may have network capture files instead. 가장 적합한 메서드를 사용합니다.Use the method that works best for you. 기록 기준을 저장하고 온라인 서비스의 동작이 변경되는 지점에서 참조하세요.Store your historical baselines and refer to them at points where you notice changes in the behavior of online services.

파일럿 중에 성능 데이터를 수집하는 이유Why collect performance data during a pilot?

기본 서비스를 파일럿하는 동안보다 기준을 세우는 것이 더 Office 365 없습니다.There is no better time to start making baselines than during a pilot of the Office 365 service. 사무실에 수천 명의 사용자가 있을 수도, 수만 명이나 다섯 명일 수도 있지만, 소수의 사용자라도 테스트를 수행하여 성능 변동을 측정할 수 있습니다.Your office may have thousands of users, hundreds of thousands, or it may have five, but even with a small number of users, you can perform tests to measure fluctuations in performance. 대기업의 경우 수백 명의 사용자로 구성되는 대표 샘플을 Office 365 수 있습니다. 따라서 문제가 발생하기 전에 발생할 수 있는 위치를 알 수 있습니다.In the case of a large company, a representative sample of several hundred users piloting Office 365 can be projected outward to several thousands so you know where issues might arise before they happen.

모든 사용자가 동시에 서비스로 이동하고 파일럿이 없음을 의미하는 소규모 회사인 경우 성능이 좋지 않은 작업 문제를 해결해야 할 수 있는 사용자에게 데이터를 표시하기 위해 성능 측정값을 유지하십시오.In the case of a small company, where on-boarding means that all users go to the service at the same time and there is no pilot, keep performance measures so that you have data to show to anyone who may have to troubleshoot a badly performing operation. 예를 들어 갑작스러운 일이 발생하면 중간 크기의 그래픽을 업로드하는 데 걸리는 시간 동안 빠르게 건물을 돌아다니는 것을 알 수 있습니다.For example, if you notice that all of a sudden you can walk around your building in the time it takes to upload a medium-sized graphic where it used to happen very quickly.

기준을 수집하는 방법How to collect baselines

모든 문제 해결 계획의 경우 최소한 다음을 식별해야 합니다.For all troubleshooting plans you need to identify these things at a minimum:

  • 사용 중이신 클라이언트 컴퓨터(컴퓨터 또는 장치 유형, IP 주소 및 문제를 유발한 작업)The client computer you're using (the type of computer or device, an IP address, and the actions that caused the issue)

  • 클라이언트 컴퓨터가 전 세계에 있는 위치(예: 이 사용자가 네트워크에 VPN을 사용하는지, 원격으로 작업하는지 또는 회사 인트라넷에서 작업하는지 여부)Where the client computer is located in the world (for example, whether this user on a VPN to the network, working remotely, or on the company intranet)

  • 클라이언트 컴퓨터가 네트워크에서 사용하는 시작 지점(트래픽이 ISP 또는 인터넷을 위해 비즈니스를 떠나는 지점)The egress point the client computer uses from your network (the point at which traffic leaves your business for an ISP or the Internet)

네트워크 관리자에서 네트워크 레이아웃을 찾을 수 있습니다.You can find out the layout of your network from the network administrator. 소규모 네트워크에 있는 경우 인터넷에 연결하는 장치를 살펴보고 레이아웃에 대한 질문이 있는 경우 ISP에 전화를 걸 수 있습니다.If you're on a small network, take a look at the devices connecting you to the Internet, and call your ISP if you have questions about the layout. 참조에 대한 최종 레이아웃의 그래픽을 생성합니다.Create a graphic of the final layout for your reference.

이 섹션은 간단한 명령줄 도구 및 메서드와 고급 도구 옵션으로 나됩니다.This section is broken into simple command-line tools and methods, and more advanced tools options. 먼저 간단한 메서드를 다산합니다.We'll cover simple methods first. 하지만 지금 성능 문제가 있는 경우 고급 방법으로 이동한 후 예제 성능 문제 해결 작업 계획을 시도해 보아야 합니다.But if you've got a performance problem right now, you should jump to advanced methods and try out the sample performance-troubleshooting action plan.

간단한 메서드Simple methods

이러한 간단한 방법의 목표는 성능에 대한 정보를 알릴 수 있도록 시간이 지날 때 간단한 성능 기준을 파악하고 적절하게 저장하는 Office 365 것입니다.The objective of these simple methods is to learn to take, understand, and properly store simple performance baselines over time so that you are informed about Office 365 performance. 다음은 이전과 같은 간단한 다이어그램입니다.Here's the very simple diagram for simple, as you've seen before:

클라이언트, 프록시 및 클라우드가 있는 기본 네트워크와 PSPing, TraceTCP 및 네트워크 추적을 제안하는 도구가 있습니다.


TraceTCP는 요청이 대상에 도달하는 데 걸리는 네트워크 홉 수(밀리초) 및 네트워크 홉 수를 표시하는 데 유용한 도구이기 때문에 이 스크린샷에 포함되어 있습니다.TraceTCP is included in this screen shot because it's a useful tool for showing, in milliseconds, how long a request takes to process, and how many network hops, or connections from one computer to the next, that the request takes to reach a destination. TraceTCP는 홉 중에 사용되는 서버의 이름을 제공하면 지원의 Microsoft Office 365 유용할 수 있습니다.TraceTCP can also give the names of servers used during hops, which can be useful to a Microsoft Office 365 troubleshooter in Support. > TraceTCP 명령은 매우 간단할 수 있습니다. >> 명령에 포트 번호를 포함해야 tracetcp.exe outlook.office365.com:443 합니다!> TraceTCP commands can be very simple, such as: > tracetcp.exe outlook.office365.com:443> Remember to include the port number in the command! > TraceTCP는 무료 다운로드이지만 Wincap에 의존합니다. > TraceTCP is a free download, but relies on Wincap. Wincap는 Netmon에서도 사용 및 설치되는 도구입니다.Wincap is a tool that is also used and installed by Netmon. 또한 고급 메서드 섹션에서 Netmon을 사용할 수 있습니다.We also use Netmon in the advanced methods section.

사무실이 여러 개인 경우 각 위치에 있는 클라이언트의 데이터 집합도 유지해야 합니다.If you have multiple offices, you'll need to keep a set of data from a client in each of those locations as well. 이 테스트에서는 대기 시간을 측정합니다 Office 365. 이 경우 요청에 대한 요청을 보내는 클라이언트와 요청에 Office 365 시간 사이의 시간을 설명하는 숫자 값입니다.This test measures latency, which, in this case, is a number value that describes the amount of time between a client sending a request to Office 365, and Office 365 responding to the request. 테스트는 클라이언트 컴퓨터의 도메인 내부에서 시작되어 네트워크 내부에서 발신 지점을 통과하고 인터넷을 통해 왕복한 후 다시 Office 365 측정합니다.The testing originates inside your domain on a client computer, and looks to measure a round trip from inside your network, out through an egress point, across the Internet to Office 365, and back.

이 경우 프록시 서버인 시작 지점을 다루는 몇 가지 방법이 있습니다.There are a few ways to deal with the egress point, in this case, the proxy server. 1에서 2까지 추적한 다음 2에서 3까지 추적한 다음 밀리초로 숫자를 추가하여 네트워크 가장자리에 최종 합계를 얻을 수 있습니다.You can either trace from 1 to 2 and then 2 to 3, and then add the numbers in milliseconds to get a final total to the edge of your network. 또는 주소의 프록시를 무시하도록 연결을 구성할 Office 365 있습니다.Or, you can configure the connection to bypass the proxy for Office 365 addresses. 방화벽, 역방향 프록시 또는 둘의 일부 조합이 있는 대규모 네트워크에서는 트래픽이 많은 URL에 대해 전달될 수 있도록 허용하는 프록시 서버에서 예외를 만들어야 할 수 있습니다.In a larger network with a firewall, reverse proxy, or some combination of the two, you may need to make exceptions on the proxy server that will allow traffic to pass for a lot of URLs. 2016에서 사용하는 끝점 목록은 Office 365 및 IP 주소 Office 365 를 참조하세요.For the list of endpoints used by Office 365, see Office 365 URLs and IP address ranges. 인증 프록시가 있는 경우 먼저 다음에 대한 예외를 테스트합니다.If you have an authenticating proxy, begin by testing exceptions for the following:

  • 포트 80 및 443Ports 80 and 443


  • 다음 URL로 아웃바운드된 연결:Connections that are outbound to any of these URLs:

  • *.microsoftonline.com*.microsoftonline.com

  • *.microsoftonline-p.com*.microsoftonline-p.com

  • *.sharepoint.com*.sharepoint.com

  • *.outlook.com*.outlook.com

  • *.lync.com*.lync.com

  • osub.microsoft.comosub.microsoft.com

모든 사용자는 프록시 간섭 또는 인증 없이 이러한 주소에 액세스하도록 허용해야 합니다.All users need to be allowed to get to these addresses without any proxy interference or authentication. 더 작은 네트워크에서 웹 브라우저의 프록시 우회 목록에 추가해야 합니다.On a smaller network, you should add these to your proxy bypass list in your web browser.

프록시의 프록시 우회 목록에 Internet Explorer 도구 인터넷 옵션 연결 > > > LAN 설정 > 고급으로 이동합니다.To add these to your proxy bypass list in Internet Explorer, go to Tools > Internet Options > Connections > LAN settings > Advanced. 고급 탭에서는 프록시 서버 및 프록시 서버 포트도 찾을 수 있습니다.The advanced tab is also where you will find your proxy server and proxy server port. 고급 단추에 액세스하려면 LAN에 프록시 서버 사용 확인란을 클릭해야 할 수 있습니다.You may need to click the checkbox Use a proxy server for your LAN, to access the Advanced button. 로컬 주소에 프록시 서버 무시가 선택되어 있는지 확인할 수 있습니다.You'll want to make sure that Bypass proxy server for local addresses is checked. 고급을 클릭하면 예외를 입력할 수 있는 텍스트 상자가 표시됩니다.Once you click Advanced, you'll see a text box where you can enter exceptions. 위에 나열된 와일드카드 URL을 세미 콜론으로 구분합니다. 예를 들면 다음과 같습니다.Separate the wildcard URLs listed above with semi-colons, for example:

*.microsoftonline.com; *.sharepoint.com*.microsoftonline.com; *.sharepoint.com

프록시를 무시하고 나면 해당 URL에서 직접 ping 또는 PsPing을 사용할 Office 365 있습니다.Once you bypass your proxy, you should be able to use ping or PsPing directly on an Office 365 URL. 다음 단계는 ping 테스트 outlook.office365.com.The next step will be to test ping outlook.office365.com. 또는 PsPing 또는 명령에 포트 번호를 제공하게 하는 다른 도구를 사용하는 경우 PsPing을 portal.microsoftonline.com:443 평균 왕복 시간을 밀리초로 볼 수 있습니다.Or, if you're using PsPing or another tool that will let you supply a port number to the command, PsPing against portal.microsoftonline.com:443 to see the average round trip time in milliseconds.

왕복 시간(RTT)은 HTTP 요청을 서버로 보내는 데 걸리는 시간을 측정하는 숫자 값입니다 outlook.office365.com 서버가 이를 확인했다는 응답을 다시 받을 수 있습니다.The round trip time, or RTT, is a number value that measures how long it takes to send a HTTP request to a server like outlook.office365.com and get a response back that acknowledges the server knows that you did it. 이 약어를 RTT로 표시하는 경우도 있습니다.You'll sometimes see this abbreviated as RTT. 이 시간은 비교적 짧아야 합니다.This should be a relatively short amount of time.

이 테스트를 실행하려면 PSPing 또는 사용자에 의해 차단되는 ICMP 패킷을 사용하지 Office 365 도구를 사용해야 합니다.You have to use PSPing or another tool that does not use ICMP packets which are blocked by Office 365 in order to do this test.

PsPing을 사용하여 전체 왕복 시간을 전체 왕복 시간(밀리초)을 Office 365 방법How to use PsPing to get an overall round trip time in milliseconds directly from an Office 365 URL

  1. 다음 단계를 완료하여 상승된 명령 프롬프트를 실행합니다.Run an elevated command prompt by completing these steps:

  2. 시작 을 클릭합니다.Click Start.

  3. 검색 시작 상자에 cmd를 입력한 다음 Ctrl+Shift+Enter를 누르고 있습니다.In the Start Search box, type cmd, and then press CTRL+SHIFT+ENTER.

  4. 사용자 계정 컨트롤 대화 상자가 나타나면 표시하는 작업이 원하는 작업으로 확인된 다음 계속을 클릭합니다.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  5. 도구(이 경우 PsPing)가 설치된 폴더로 이동한 후 다음 url을 Office 365 테스트합니다.Navigate to the folder where the tool (in this case PsPing) is installed and test these Office 365 URLs:

  • psping portal.office.com:443psping portal.office.com:443

  • psping microsoft-my.sharepoint.com:443psping microsoft-my.sharepoint.com:443

  • psping outlook.office365.com:443psping outlook.office365.com:443

  • psping www.yammer.com:443psping www.yammer.com:443

    포트 443을 microsoft-my.sharepoint.com PSPing 명령입니다.

포트 번호 443을 포함해야 합니다.Be sure to include the port number of 443. 이 Office 365 암호화된 채널에서 작동합니다.Remember that Office 365 works on an encrypted channel. 포트 번호 없이 PsPing을 사용하면 요청이 실패합니다.If you PsPing without the port number, your request will fail. 짧은 목록을 ping한 후 평균 시간(밀리초)을 찾아보아야 합니다.Once you've pinged your short list, look for the Average time in milliseconds (ms). 이는 기록하려는 것입니다!That is what you want to record!

왕복 시간이 2.8밀리초인 클라이언트에서 프록시로 PSPing을 프록시하는 그림을 보여주는 그래픽입니다.

프록시 우회에 익숙하지 않은 경우 단계별 방법을 선호하는 경우 먼저 프록시 서버의 이름을 찾아야 합니다.If you're not familiar with proxy bypass, and prefer to take things step-by-step, you need to first find out the name of your proxy server. In Internet Explorer go to > Tools Internet Options > Connections > LAN settings > Advanced.In Internet Explorer go to Tools > Internet Options > Connections > LAN settings > Advanced. 고급 탭에서 프록시 서버가 나열됩니다.The Advanced tab is where you will see your proxy server listed. 이 작업을 완료하여 명령 프롬프트에서 프록시 서버를 Ping합니다.Ping that proxy server at a command prompt by completing this task:

프록시 서버를 ping하고 1~2단계의 왕복 값을 밀리초(밀리초)To ping the proxy server and get a round trip value in milliseconds for stage 1 to 2

  1. 다음 단계를 완료하여 상승된 명령 프롬프트를 실행합니다.Run an elevated command prompt by completing these steps:

  2. 시작 을 클릭합니다.Click Start.

  3. 검색 시작 상자에 cmd를 입력한 다음 Ctrl+Shift+Enter를 누르고 있습니다.In the Start Search box, type cmd, and then press CTRL+SHIFT+ENTER.

  4. 사용자 계정 컨트롤 대화 상자가 나타나면 표시하는 작업이 원하는 작업으로 확인된 다음 계속을 클릭합니다.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  5. ping을 <the name of the proxy server your browser uses, or the IP address of the proxy server> 입력한 다음 Enter를 누를 수 있습니다.Type ping <the name of the proxy server your browser uses, or the IP address of the proxy server> and then press ENTER. PsPing 또는 다른 도구가 설치된 경우 대신 해당 도구를 사용할 수 있습니다.If you have PsPing, or some other tool, installed, you can choose to use that tool instead.

    명령은 다음과 같은 예와 같을 수 있습니다.Your command may look like any of these examples:

  • ping ourproxy.ourdomain.industry.business.comping ourproxy.ourdomain.industry.business.com

  • ping

  • ping ourproxyping ourproxy

  • psping ourproxy.ourdomain.industry.business.com:80psping ourproxy.ourdomain.industry.business.com:80

  • psping

  • psping ourproxy:80psping ourproxy:80

  1. 추적에서 테스트 패킷 전송을 중지하면 평균(밀리초)을 나열하는 작은 요약이 표시됩니다.When the trace stops sending test packets, you'll get a small summary that lists an average, in milliseconds, and that's the value you're after. 프롬프트의 스크린샷을 촬영하고 이름 규칙을 사용하여 저장합니다.Take a screen shot of the prompt and save it using your naming convention. 이때 값을 사용하여 다이어그램을 채우는 데도 도움이 될 수 있습니다.At this point it may also help to fill in the diagram with the value.

새벽에 추적을 하다가 클라이언트가 프록시(또는 인터넷으로 나가는 모든 발신 서버)에 빠르게 도착할 수 있습니다.Maybe you've taken a trace in the early morning, and your client can get to the proxy (or whatever egress server exits to the Internet) quickly. 이 경우 번호는 다음과 같이 될 수 있습니다.In this case, your numbers may look like this:

클라이언트에서 프록시로의 왕복 시간을 2.8밀리초로 표시하는 그래픽입니다.

클라이언트 컴퓨터가 프록시(또는 발신) 서버에 액세스할 수 있는 몇 가지 선택 중 하나인 경우 해당 컴퓨터에 원격으로 연결하고 명령 프롬프트를 PsPing에 실행하여 테스트의 다음 단계 중 하나를 실행할 수 Office 365 있습니다.If your client computer is one of the select few with access to the proxy (or egress) server, you can run the next leg of the test by remotely connecting to that computer, running the command prompt to PsPing to an Office 365 URL from there. 해당 컴퓨터에 액세스할 수 없는 경우 네트워크 리소스에 문의하여 다음 다리에 대한 도움을 받을 수 있으며 정확한 번호를 얻을 수 있습니다.If you don't have access to that computer, you can contact your network resources for help with the next leg and get exact numbers that way. 가능하지 않은 경우 해당 Office 365 URL에 대해 PsPing을 사용하여 프록시 서버에 대해 PsPing 또는 Ping 시간을 비교합니다.If that's not possible, take a PsPing against the Office 365 URL in question and compare it to the PsPing or Ping time against your proxy server.

예를 들어 클라이언트에서 Office 365 URL까지의 51.84밀리초가 있으며 클라이언트에서 프록시(또는 발신 지점)까지의 2.8밀리초가 있는 경우, 시작부터 시작까지의 49.04밀리초가 Office 365.For example, if you have 51.84 milliseconds from the client to the Office 365 URL, and you have 2.8 milliseconds from the client to the proxy (or egress point), then you have 49.04 milliseconds from the egress to Office 365. 마찬가지로 하루 높이 동안 클라이언트에서 프록시로의 PsPing 값이 12.25밀리초인 경우 클라이언트에서 Office 365 URL로 프록시를 62.01밀리초를 사용하는 경우 프록시가 Office 365 URL로 이동하는 평균 값은 49.76밀리초입니다.Likewise, if you have a PsPing of 12.25 milliseconds from the client to the proxy during the height of the day, and 62.01 milliseconds from the client to the Office 365 URL, then your average value for the proxy egress to the Office 365 URL is 49.76 milliseconds.

값을 빼기 위해 클라이언트에서 프록시로의 ping을 Office 365 수 있는 추가 그래픽입니다.

문제 해결 측면에서 이러한 기준을 유지하는 것에서 흥미로운 것을 발견할 수 있습니다.In terms of troubleshooting, you may find something interesting just from keeping these baselines. 예를 들어 일반적으로 프록시 또는 전송 지점에서 40~59밀리초 정도의 대기 시간이 있는 경우 Office 365, 클라이언트가 프록시 또는 발신 지점 대기 시간 약 3~7밀리초(해당 시간 동안 표시하는 네트워크 트래픽의 양에 따라 다를 수 있습니다.) 프록시 또는 발신 기준에 최근 3개의 클라이언트가 45밀리초의 대기 시간을 표시하는 경우 문제가 있다는 것을 확실하게 알 수 있습니다.For example, if you find that you generally have about 40 to 59 milliseconds of latency from the proxy or egress point to the Office 365 URL, and have a client to proxy or egress point latency of about 3 to 7 milliseconds (depending on the amount network traffic you're seeing during that time of day) then you will surely know something is problematic if your last three client to proxy or egress baselines show a latency of 45 milliseconds.

고급 메서드Advanced methods

네트워크 추적에 대한 인터넷 요청과 함께 Office 365 정보를 확인하려면 네트워크 추적에 익숙해지야 합니다.If you really want to know what is happening with your Internet requests to Office 365, you need to become familiar with network traces. HTTPWatch, Netmon, 메시지 분석기, Wireshark, Fiddler, 개발자 대시보드 도구 또는 기타 추적에 선호하는 도구는 해당 도구가 네트워크 트래픽을 캡처하고 필터링할 수 있는 한 아무 도구나 상관이 없습니다.It does not matter which tools you prefer for these traces, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard tool or any other will do as long as that tool can capture and filter network traffic. 이 섹션에서는 이러한 도구를 두 개 이상 실행하여 문제를 보다 완전한 그림으로 보는 것이 좋습니다.You'll see in this section that it's beneficial to run more than one of these tools to get a more complete picture of the problem. 테스트할 때 이러한 도구 중 일부는 자체에서 Proxies 역할을 합니다.When you're testing, some of these tools also act as proxies in their own right. 도우미 문서, 성능 문제 해결 계획인 Office 365 Netmon 3.4, HTTPWatch 또는 WireShark를 포함합니다.Tools used in the companion article, Performance troubleshooting plan for Office 365, include Netmon 3.4, HTTPWatch, or WireShark.

성능 기준을 세우는 것은 이 방법의 간단한 부분으로, 대부분의 단계는 성능 문제를 해결할 때와 동일합니다.Taking a performance baseline is the simple part of this method, and many of the steps are the same as when you troubleshoot a performance issue. 성능 기준을 만드는 고급 방법을 사용하려면 네트워크 추적을 받아서 저장해야 합니다.The more advanced methods of creating baselines for performance requires you to take and store network traces. 이 문서의 예제는 대부분 SharePoint Online을 사용하지만 테스트 및 기록을 구독하는 Office 365 서비스 전체에서 일반적인 작업 목록을 개발해야 합니다.Most of the examples in this article use SharePoint Online, but you should develop a list of common actions across the Office 365 services to which you subscribe to test and record. 기준 예는 다음과 같습니다.Here is a baseline example:

  • SPO에 대한 기준 목록 - ** 1단계: ** SPO 웹 사이트의 홈 페이지를 찾아보고 네트워크 추적을 합니다.Baseline list for SPO - ** Step 1: ** Browse the home page of the SPO website and do a network trace. 추적을 저장합니다.Save the trace.

  • SPO에 대한 기준 목록 - 2단계: 검색을 통해 용어(예: 회사 이름)Enterprise 검색하고 네트워크 추적을 합니다.Baseline list for SPO - Step 2: Search for a term (such as your company name) via Enterprise Search and do a network trace. 추적을 저장합니다.Save the trace.

  • SPO에 대한 기준 목록 - 3단계: 업로드 온라인 문서 라이브러리에 큰 파일을 SharePoint 네트워크 추적을 합니다.Baseline list for SPO - Step 3: Upload a large file to a SharePoint Online document library and do a network trace. 추적을 저장합니다.Save the trace.

  • SPO에 대한 기준 목록 - 4단계: OneDrive 웹 사이트의 홈 페이지를 찾아 네트워크 추적을 합니다.Baseline list for SPO - Step 4: Browse the home page of the OneDrive website and do a network trace. 추적을 저장합니다.Save the trace.

이 목록에는 사용자가 온라인에서 수행한 가장 중요한 일반적인 SharePoint 포함되어야 합니다.This list should include the most important common actions that users take against SharePoint Online. 마지막 단계에서는 비즈니스용 OneDrive 진행하는 추적을 위해 회사에서 사용자 지정하는 SharePoint Online 홈 페이지 로드와 사용자 지정되지 비즈니스용 OneDrive 홈 페이지 간의 비교를 빌드합니다.Notice that the last step, to trace going to OneDrive for Business, builds-in a comparison between the load of the SharePoint Online home page (which is often customized by companies) and OneDrive for Business home page, which is seldom customized. 이 테스트는 온라인 사이트의 로드 속도가 느려질 때 SharePoint 테스트입니다.This is a very basic test when it comes to a slow-loading SharePoint Online site. 이러한 차이점에 대한 기록을 테스트에 빌드할 수 있습니다.You can build a record of this difference into your testing.

성능 문제가 있는 경우 대부분의 단계는 기준을 세울 때와 동일합니다.If you are in the middle of a performance problem, many of the steps are the same as when taking a baseline. 네트워크 추적이 중요해지기 때문에 다음에 중요한 추적을 진행하는 방법을 처리합니다.Network traces become critical, so we'll handle how to take the important traces next.

성능 문제를 해결하려면 지금 성능 문제가 발생하면 추적을 해야 합니다.To tackle a performance problem, right now , you need to be taking a trace at the time you are experiencing the performance issue. 로그를 수집하는 데 사용할 수 있는 적절한 도구를 제공해야 합니다. 즉, 수행할 수 있는 최상의 정보를 수집하기 위해 수행할 문제 해결 작업 목록과 같은 작업 계획이 필요합니다.You need to have the proper tools available to gather logs, and you need an action plan, that is, a list of troubleshooting actions to take to gather the best information that you can. 가장 먼저 할 일은 시간을 반영하는 폴더에 파일을 저장할 수 있도록 테스트의 날짜와 시간을 기록하는 것입니다.The first thing to do is record the date and time of the test so that the files can be saved in a folder that reflect the timing. 그런 다음 문제 단계로 좁혀야 합니다.Next, narrow down to the problem steps themselves. 테스트에 사용할 정확한 단계입니다.These are the exact steps you will use for testing. 기본 사항도 잊지 마세요. 문제가 Outlook 서비스에서만 문제 동작이 발생하는지 기록해야 Office 365.Don't forget the basics: if the issue is only with Outlook, make sure to record that the problem behavior happens in only one Office 365 service. 이 문제의 범위를 좁히면 해결할 수 있는 점에 집중하는 데 도움이 됩니다.Narrowing down the scope of this issue will help you to focus on something you can resolve.

참고 항목See also

Office 365 끝점 관리Managing Office 365 endpoints