Penyelarasan kinerja Office 365 menggunakan garis dasar dan riwayat kinerja

Ada beberapa cara sederhana untuk memeriksa kinerja koneksi antara Office 365 dan bisnis Anda yang akan memungkinkan Anda menetapkan garis dasar konektivitas Anda secara kasar. Mengetahui riwayat kinerja koneksi komputer klien bisa membantu Anda mendeteksi masalah yang muncul lebih awal, mengidentifikasi, dan memprediksi masalah.

Jika Anda tidak terbiasa mengerjakan masalah kinerja, artikel ini dirancang untuk membantu Anda mempertimbangkan beberapa pertanyaan umum, seperti Bagaimana Anda mengetahui masalah yang Anda lihat adalah masalah kinerja dan bukan insiden layanan Office 365? Bagaimana Anda bisa merencanakan kinerja yang bagus, jangka panjang? Bagaimana Anda bisa tetap memperhatikan kinerja? Jika tim atau klien Anda melihat kinerja yang lambat saat menggunakan Office 365, dan Anda bertanya-tanya tentang salah satu dari pertanyaan ini, baca terus.

Penting: Mengalami masalah kinerja antara klien Anda dan Office 365 sekarang? Ikuti langkah-langkah yang dijelaskan dalam Rencana pemecahan masalah kinerja untuk Office 365.

Ada yang harus Anda ketahui tentang kinerja Office 365

Office 365 berada dalam jaringan khusus Microsoft berkapasitas tinggi yang dipantau bukan saja dengan otomatisasi tapi juga dengan orang benaran. Sebagian dari peran memelihara Office 365 awan adalah mengembangkan penyelarasan dan perampingan dalam kinerja di saat memungkinkan. Karena klien Office 365 awan harus tersambung melalui internet, ada pula upaya berkelanjutan untuk menyelaraskan kinerja di seluruh layanan Office 365. Peningkatan kinerja tidak pernah benar-benar berhenti di awan, dan ada banyak akumulasi pengalaman dalam memelihara awan tetap sehat dan cepat. Jika Anda mengalami masalah kinerja dalam menyambungkan dari lokasi Anda ke Office 365, paling baik jika Anda tidak memulai dan tunggulah kasus Dukungan. Sebaliknya, Anda harus mulai menyelidiki masalah dari 'dalam ke luar'. Yaitu, mulai dari dalam jaringan Anda, dan teruskan ke luar ke Office 365. Sebelum Anda membuka kasus dengan menghubungi Dukungan Office 365, Anda bisa mengumpulkan data dan mengambil tindakan yang akan menjelajahi, dan mungkin mengatasi masalah Anda.

Penting: Perhatikanlah perencanaan kapasitas dan batasan di Office 365. Informasi tersebut akan menuntun Anda ketika mencoba memecahkan masalah kinerja. Berikut tautan ke Deskripsi Layanan Platform Office 365. Hub ini merupakan hub pusat, dan semua layanan yang ditawarkan oleh Office 365 memiliki tautan menuju ke Deskripsi Layanannya masing-masing dari sini. Artinya, jika Anda perlu melihat batasan standar untuk SharePoint Online, klik Deskripsi Layanan SharePoint Online, lalu temukan Bagian Batasan SharePoint Online.

Pastikan Anda masuk ke pemecahan masalah dengan pemahaman bahwa kinerja adalah timbangan geser, ini tidak berbicara tentang mencapai sebuah nilai ideal dan mempertahankannya secara permanen (jika Anda meyakini memang demikian, maka tugas sesekali yang menggunakan bandwidth tinggi seperti sejumlah besar pengguna, atau melakukan migrasi data yang besar akan menjadi sangat menegangkan -- jadi rencanakanlah dampak kinerja). Anda bisa, dan seharusnya, memiliki ide kasar tentang target kinerja Anda namun banyak variabel yang bermain dalam kinerja, oleh karena itu, kinerja itu beragam. Itulah hakikat kinerja.

Pemecahan masalah kinerja bukanlah tentang mencapai tujuan tertentu dan mempertahankan angka tersebut tanpa batas, ini berbicara tentang memperbaiki aktivitas yang sudah ada, dengan mengingat semua variabel.

Oke, seperti apa masalah kinerja itu?

Pertama, Anda harus memastikan bahwa apa yang Anda alami adalah masalah kinerja, bukan insiden layanan. Masalah kinerja berbeda dari insiden layanan di Office 365. Berikut ini cara membedakannya.

Jika Office 365 mengalami masalah, itu adalah insiden layanan. Anda akan melihat ikon merah atau kuning di bawah Kesehatan saat Ini di pusat admin Office 365, Anda mungkin juga melihat kinerja yang lambat pada klien komputer yang menyambungkan ke Office 365. Misalnya, jika laporan Kesehatan saat ini merah dan Anda melihat ikon Menyelidiki samping Exchange, Anda mungkin juga akan menerima panggilan dari orang-orang di organisasi Anda yang mengeluh bahwa kotak surat yang menggunakan klien Exchange Online berkinerja buruk. Dalam hal itu, masuk akal untuk mengasumsikan bahwa kinerja Exchange Online Anda telah menjadi korban masalah dalam Layanan.

Dasbor Kesehatan Office 365 dengan semua beban kerja memperlihatkan warna hijau, kecuali Exchange, yang memperlihatkan Layanan yang Dipulihkan.

Pada titik ini, Anda, admin Office 365, harus memeriksa Kesehatan saat ini lalu Tampilkan detail dan riwayat, dengan sering agar Anda tetap mengetahui kabar terbaru tentang pelayanan yang kami lakukan dalam sistem. Dasbor Kesehatan saat ini dibuat untuk memberi Anda kabar terbaru tentang perubahan pada layanan serta masalah-masalah dalam layanan. Catatan dan penjelasan yang ditulis tentang riwayat kesehatan, admin ke admin, ada di sana untuk membantu Anda mengukur dampak dan membuat Anda tetap tahu tentang pekerjaan yang sedang berjalan.

Gambar dasbor kesehatan Office 365 menjelaskan bahwa layanan Exchange Online telah dipulihkan, dan alasannya.

Masalah kinerja bukanlah insiden layanan, meskipun insiden dapat menimbulkan kinerja yang lambat. Masalah kinerja mungkin terlihat seperti ini:

  • Masalah kinerja yang terjadi terlepas dari seperti apa Kesehatan saat ini yang dilaporkan oleh pusat admin Office 365 ke layanan.

  • Perilaku yang dulunya relatif mulus memakan waktu penyelesaian yang lama atau bahkan tidak pernah selesai.

  • Anda pun bisa mereplikasi masalah, atau, setidaknya, Anda tahu ini akan terjadi jika Anda melakukan serangkaian langkah yang tepat.

  • Jika masalah terjadi sebentar-sebentar, masih ada pola, misalnya, Anda tahu bahwa pada pukul 10:00 Anda akan menerima panggilan dari pengguna yang tidak bisa mengakses Office 365 dengan andal, dan bahwa panggilan akan mati sekitar siang hari.

Ini mungkin terdengar tidak asing; mungkin terlalu tidak asing. Begitu Anda mengetahui bahwa itu adalah masalah kinerja, pertanyaan menjadi, "Apa yang akan Anda lakukan berikutnya?" Bagian selanjutnya artikel ini persis membantu Anda menentukan langkah berikutnya.

Cara menetapkan dan menguji masalah kinerja

Masalah kinerja sering muncul sepanjang waktu, jadi menentukan masalah yang sesungguhnya bisa jadi sangat menyulitkan. Anda perlu membuat pernyataan masalah yang bagus dan memahami konteks masalah dengan baik, lalu melakukan langkah-langkah pengujian berulang untuk mengatasinya. Jika tidak, Anda mungkin tersesat, meskipun bukan karena kesalahan Anda. Mengapa? Berikut ini ada beberapa contoh pernyataan masalah yang tidak menyediakan cukup informasi:

  • Beralih dari Kotak Masuk saya ke Kalender menggunakan sesuatu yang tidak saya perhatikan sebelumnya, dan kini saatnya santai. Bisakah Anda membuatnya berperilaku seperti sebelumnya?

  • Mengunggah file saya ke SharePoint Online memakan waktu yang sangat lama. Mengapa lambat di sore hari, tapi di waktu lain cepat? Bisakah agar cepat?

Ada beberapa tantangan besar yang dimunculkan oleh pertanyaan masalah di atas. Secara spesifik, ada banyak ambiguitas yang harus dihadapi. misalnya:

  • Tidak jelas bagaimana cara beralih antara Kotak Masuk dan Kalender pada laptop.

  • Saat pengguna mengatakan, "Bisakah cepat", seperti apa "cepat" itu?

  • Berapa lama "sangat lama" itu? Apakah beberapa detik, atau menit, atau bisakah pengguna pergi makan siang dan peralihan akan selesai sepulun menit setelah pengguna kembali?

Semua ini tanpa mempertimbangkan bahwa admin dan pemecah masalah tidak bisa mengetahui banyak rincian dari pernyataan masalah seperti di atas. Misalnya, saat masalah mulai terjadi; Bahwa pengguna bekerja dari rumah, dan hanya melihat peralihan yang lambat saat berada di jaringan di rumah; Bahwa pengguna harus menjalankan beberapa aplikasi yang intensif menggunakan RAM pada klien lokal, atau pengguna menjalankan sistem operasi yang lebih lama atau belum menjalankan pembaruan terbaru.

Saat pengguna melaporkan masalah kinerja, ada banyak informasi yang perlu dikumpulkan. Mengumpulkan informasi ini merupakan bagian dari proses yang disebut pencakupan masalah, atau menyelidikinya. Berikut ini adalah daftar pencakupan dasar yang bisa Anda gunakan untuk mengumpulkan informasi tentang masalah kinerja Anda. Daftar ini tidak menyeluruh, namun dapat dipakai untuk memulai daftar Anda:

  • Pada tanggal berapa masalah terjadi, dan sekitar jam berapa, siang atau malam?

  • Jenis komputer klien apa yang Anda gunakan, dan bagaimana komputer itu tersambung ke jaringan bisnis (VPN, Berkabel, Nirkabel)?

  • Apakah Anda bekerja secara jarak jauh atau apakah Anda di kantor?

  • Apakah Anda mencoba tindakan yang sama pada komputer lain dan melihat sama perilaku yang sama?

  • Telusuri langkah-langkah yang menimbulkan masalah sehingga Anda bisa menulis tindakan yang Anda lakukan.

  • Seberapa lambat kinerjanya dalam hitungan detik atau menit?

  • Di mana lokasi Anda?

Beberapa pertanyaan ini lebih jelas dibandingkan dengan yang lain. Sebagian besar orang akan memahami bahwa pemecah masalah memerlukan langkah-langkah persis untuk mereproduksi masalah. Lagipula, bagaimana lagi Anda bisa merekam apa yang salah, dan bagaimana lagi Anda bisa menguji apakah masalah tersebut sudah diperbaiki? Hal-hal yang kurang jelas adalah hal-hal seperti "Apa tanggal dan waktu apakah Anda melihat masalah?", dan "Di mana di seluruh dunia Anda terletak?", informasi yang bisa digunakan dalam dipindahkan bersamaan. Bergantung pada kapan pengguna ini bekerja, beberapa jam perbedaan waktu mungkin berarti pemeliharaan sedang berlangsung pada bagian-bagian jaringan perusahaan Anda. Jika, misalnya, perusahaan Anda memiliki penerapan hibrid, seperti Pencarian SharePoint hibrid, yang indeksnya bisa dicari oleh kueri baik dalam SharePoint Online dan SharePoint Server 2013, pembaruan mungkin sedang berlangsung di layanan di tempat. Jika perusahaan Anda seluruhnya menggunakan awan, pemeliharaan sistem mungkin mencakup menambahkan atau menghapus perangkat keras jaringan, meluncurkan pembaruan yang mencakup seluruh perusahaan, atau membuat perubahan pada DNS, atau infrastruktur inti lainnya.

Saat Anda memecahkan masalah kinerja, ini sedikit mirip dengan tempat kejadian perkara, Anda perlu akurat dan saksama untuk menarik kesimpulan dari bukti. Untuk melakukan ini, Anda harus mendapatkan pernyataan masalah yang bagus dengan mengumpulkan bukti. Ini harus mencakup konteks komputer, konteks pengguna, kapan masalah bermula, dan langkah-langkah tepat apa yang mengekspos masalah kinerja ini. Pernyataan masalah ini masalah harus berada dan tetap berada di halaman teratas catatan Anda. Dengan menelusuri kembali pernyataan masalah lagi setelah Anda mengerjakan resolusinya, Anda mengambil langkah-langkah untuk menguji dan membuktikan apakah tindakan yang Anda ambil telah memecahkan masalah ini. Ini penting guna mengetahui apakah pekerjaan Anda di sana sudah selesai.

Tahukah Anda seperti apa kelihatannya kinerja yang baik?

Jika Anda sedang apes, tidak ada yang tahu. Tidak ada yang punya angkanya. Itu berarti tidak ada seorang pun yang bisa menjawab pertanyaan sederhana "Kira-kira berapa detik biasanya waktu yang diperlukan untuk memunculkan sebuah Kotak Masuk di Office 365? ", atau "Berapa lama bisanya waktu yang diperlukan Eksekutif menjalani Rapat Lync Online? ", yang merupakan skenario umum bagi banyak perusahaan.

Apa yang hilang di sini adalah baseline kinerja.

Baseline memberi konteks untuk kinerja Anda. Anda harus mengambil baseline dari kadang-kadang hingga sering, bergantung pada kebutuhan perusahaan Anda. Jika Anda adalah perusahaan yang lebih besar, tim Operasi Anda mungkin sudah mengambil baseline untuk lingkungan di tempat Anda. Misalnya, jika Anda melakukan patch semua server Exchange pada Senin pertama dalam bulan itu, dan semua server SharePoint Anda pada Senin ketiga, tim Operasi Anda mungkin memiliki daftar tugas dan skenario yang dijalankan pasca-patching, untuk membuktikan bahwa fungsi-fungsi penting beroperasi. Misalnya, membuka Kotak Masuk, mengklik Kirim/Terima, dan memastikan folder perbarui, atau, di SharePoint, menelusuri halaman utama situs itu, masuk ke halaman Pencarian perusahaan, melakukan pencarian yang mengembalikan hasil.

Jika aplikasi Anda berada di Office 365, beberapa yang baseline paling fundamental yang bisa Anda gunakan mengukur waktu (dalam milidetik) dari komputer klien dalam jaringan Anda, ke titik keluar, atau titik di mana Anda meninggalkan jaringan Anda dan keluar menuju Office 365. Berikut adalah beberapabaseline yang sangat berguna yang bisa Anda selidiki dan catat:

  • Mengidentifikasi perangkat antara komputer klien dan titik keluar, misalnya, server proksi Anda.

    • Anda perlu mengetahui perangkat Anda sehingga Anda memiliki konteks (alamat IP, tipe perangkat, dan lain-lain) untuk masalah kinerja apa pun yang timbul.

    • Server proksi adalah titik keluar umum, jadi Anda bisa memeriksa browser web untuk melihat apa server proksi apa yang disetelnya untuk digunakan, jika ada.

    • Ada alat pihak ketiga yang bisa menemukan dan memetakan jaringan Anda, namun cara paling aman untuk mengetahui perangkat Anda adalah dengan meminta anggota tim jaringan Anda.

  • Mengidentifikasi penyedia layanan Internet (ISP) Anda, tuliskan informasi kontak mereka, dan tanyakan berapa banyak sirkuit dan berapa banyak bandwidth yang Anda miliki.

  • Dalam perusahaan Anda, identifikasi sumber daya untuk perangkat antara klien Anda dan keluar titik, atau mengidentifikasi sebuah kontak darurat untuk berbicara dengan tentang jaringan masalah.

Berikut adalah beberapa baseline yang dapat dikalkulasi untuk Anda menggunakan pengujian sederhana menggunakan alat.

  • Waktu dari komputer klien Anda ke titik keluar dalam dalam milidetik

  • Waktu dari titik keluar ke Office 365 dalam milidetik

  • Lokasi di dunia server yang memecahkan URL untuk Office 365 saat Anda menelusuri

  • Kecepatan resolusi DNS ISP Anda dalam milidetik, inkonsistensi dalam paket kedatangan (jitter jaringan), waktu unggah dan unduh dalam dalam milidetik

Jika Anda tidak familiar dengan cara menjalankan langkah-langkah ini, kita akan membahas hal ini lebih detail dalam artike ini.

Apa yang dimaksud dengan baseline?

Anda akan mengetahui dampaknya ketika semua hal berjalan buruk, tetapi jika Anda tidak tahu mengetahui data kinerja secara historis Anda, tidak mungkin bisa mengetahui konteks seberapa buruk masalah itu dan kapan. Jadi, tanpa baseline Anda kehilangan petunjuk kunci untuk memecahkan teka-teki: gambar pada kotak teka-teki. Dalam pemecahan masalah kinerja, Anda membutuhkan titik perbandingan. Baseline kinerja sederhana baseline tidak sulit dijalankan. Tim operasional Anda dapat ditugasi menjalankan ini secara terjadwal. Misalnya, katakanlah koneksi Anda terlihat seperti ini:

Grafik jaringan dasar memperlihatkan klien, proksi, dan awan Office 365.

Itu berarti Anda sudah memeriksa dengan tim jaringan Anda dan menemukan bahwa Anda meninggalkan jaringan perusahaan Anda untuk mengakses internet melalui server proksi, dan bahwa proksi menangani semua permintaan komputer klien Anda mengirimnya ke awan. Dalam kasus ini, Anda harus menggambar versi sederhana koneksi Anda yang mencantumkan semua perangkat yang mengintervensi. Sekarang, sisipkan alat yang bisa Anda gunakan untuk menguji kinerja antara klien, titik keluar (di mana Anda meninggalkan jaringan Anda untuk internet), dan awan Office 365.

Jaringan dasar dengan klien, proksi, dan awan, serta alat saran PSPing, TraceTCP, dan jejak jaringan.

Daftar opsinya tercantum sebagai Sederhana dan Tingkat Lanjut karena tingkay keahlian Anda perlukan untuk menemukan data kinerja. Penelusuran jaringan akan memakan banyak waktu, dibandingkan dengan menjalankan alat baris-perintah seperti PsPing dan TraceTCP. Dua alat baris perintah ini dipilih karena keduanya tidak menggunakan paket ICMP yang akan diblokir oleh Office 365, dan keduanya memberi waktu dalam milidetik yang dibutuhkan untuk meninggalkan komputer klien, atau server proksi (jika Anda memiliki akses) dan tiba di Office 365. Setiap individu yang melompat dari satu komputer ke komputer lainnya akan berakhir dengan nilai waktu, dan itu bagus untuk baseline! Sama pentingnya, alat baris perintah ini memungkinkan Anda menambahkan nomor port ke perintah, ini berguna karena Office 365 berkomunikasi melalui port 443, yang merupakan port digunakan oleh Secure Sockets Layer dan Transport Layer Security (SSL dan TLS). Namun, alat pihak ketiga lainnya mungkin merupakan solusi yang lebih baik untuk situasi Anda. Microsoft tidak mendukung semua alat ini, jadi jika, karena alasan tertentu, Anda tidak bisa membuat PsPing dan TraceTCP berfungsi, beralihlah ke penelusuran jaringan dengan alat seperti Netmon.

Anda bisa menjalankan baseline sebelum jam kerja, lagi selama penggunaan berat, lalu lagi setelah berjam-jam. Ini berarti Anda mungkin memiliki struktur folder yang pada akhirnya tampak seperti ini:

Grafik mengusulkan cara untuk menata data kinerja Anda ke dalam folder.

Anda juga harus memilih konvensi penamaan untuk file Anda. Berikut ini ada beberapa contoh:

  • 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

Ada banyak cara berbeda untuk melakukan ini, namun menggunakan format <dateTime><what's happening in the test> adalah cara yang bagus untuk memulai. Rajin mengurusi hal ini akan sangat membantu saat Anda mencoba mengatasi masalah di kemudian hari. Nanti, Anda akan dapat mengatakan "Saya melakukan dua penelusuran pada tanggal 8 Februari, satu menunjukkan kinerja yang baik dan satu memperlihatkan kinerja yang buruk, jadi kita bisa membandingkannya". Ini sangat berguna untuk pemecahan masalah.

Anda untuk memiliki cara yang terorganisir untuk mempertahankan baseline historis Anda. Dalam contoh ini, metode sederhana menghasilkan tiga output baris perintah dan hasilnya dikumpulkan sebagai cuplikan layar, namun Anda mungkin malah file tangkapan jaringan. Menggunakan metode yang paling pas untuk Anda. Simpan baseline histori Anda dan rujuklah pada itu pada saat-saat Anda melihat perubahan dalam perilaku layanan online.

Mengapa mengumpulkan kinerja data selama masa percobaan

Tidak ada waktu yang lebih baik untuk memulai membuat baseline daripada selama masa percobaan layanan Office 365. Office Anda mungkin memiliki ribuan pengguna, ratusan ribu, atau mungkin lima, tapi bahkan dengan sejumlah kecil pengguna, Anda bisa melakukan pengujian untuk mengukur fluktuasi dalam kinerja. Dalam kasus perusahaan besar, sampel representatif dari beberapa ratus pengguna yang mencoba Office 365 dapat diproyeksikan hingga ke beberapa ribu sehingga asal masalah sebelum masalah terjadi.

Dalam kasus perusahaan kecil, di mana on-boarding berarti bahwa semua pengguna masuk ke layanan pada saat yang sama dan tidak ada percobaan, simpanlah pengukuran kinerja sehingga Anda memiliki data untuk diperlihatkan kepada siapa saja yang mungkin harus memecahkan masalah operasi yang berjalan dengan buruk. Misalnya, jika Anda diberi tahu bahwa Anda bisa mengelilingi gedung dalam waktu yang diperlukan untuk mengunggah grafis berukuran sedang yang biasanya berlangsung sangat cepat.

Cara mengumpulkan baseline

Untuk semua rencana pemecahan masalah, minimal Anda perlu mengidentifikasi hal-hal berikut ini:

  • Komputer klien yang Anda gunakan (tipe komputer atau perangkat, alamat IP, dan tindakan yang menyebabkan masalah)

  • Di mana komputer klien berada di seluruh dunia (misalnya, apakah pengguna ini berada di VPN jaringan, bekerja dari jarak jauh, atau di intranet perusahaan)

  • Titik keluar yang digunakan komputer klien dari jaringan Anda (titik di mana lalu lintas meninggalkan bisnis Anda untuk ISP atau internet)

Anda bisa menemukan tata letak jaringan Anda dari administrator jaringan. Jika Anda berada dalam jaringan kecil, lihatlah perangkat yang Anda sambungkan ke internet serta panggilan ISP jika Anda memiliki pertanyaan tentang tata letak. Membuat grafik final tata letak untuk rujukan Anda.

Bagian ini dipecah dipecah ke dalam alat dan metode baris perintah serta opsi alat tingkat lanjut lainnya. Kita akan membahas metode sederhana terlebih dahulu. Tapi jika Anda mengalami masalah kinerja sekarang, Anda harus melompat ke metode tingkat lanjut dan mencoba contoh rencana tindakan pemecahan masalah kinerja.

Metode sederhana

Tujuan dari metode sederhana ini adalah untuk mempelajari cara mengambil, memahami, dan menyimpan baseline kinerja sederhana seiring waktu sehingga Anda akan tahu informasi tentang kinerja Office 365. Berikut ini diagram sederhana untuk baseline kinerja sederhana, seperti yang telah Anda lihat sebelumnya:

Jaringan dasar dengan klien, proksi, dan awan, serta alat saran PSPing, TraceTCP, dan jejak jaringan.

Catatan: 

  • TraceTCP disertakan dalam cuplikan layar ini karena ini merupakan alat yang berguna untuk memperlihatkan berapa lama waktu yang dibutuhkan untuk memproses dalam milidetik, dan berapa banyak hop jaringan, atau koneksi dari satu komputer ke komputer berikutnya, yang diperlukan permintaan untuk mencapai suatu tujuan. TraceTCP juga bisa memberi nama server yang digunakan selama hop, yang sangat berguna Microsoft Office 365 troubleshooter di Dukungan.

  • Perintah TraceTCP bisa jadi sangat sederhana, seperti:

  • tracetcp.exe outlook.office365.com:443

  • Ingatlah untuk menyertakan nomor port pada perintah!

  • TraceTCP merupakan unduhan gratis, tetapi bergantung pada Wincap. Wincap adalah alat yang juga digunakan dan diinstal oleh Netmon. Kami juga menggunakan Netmon dalam bagian metode tingkat lanjut.

Jika Anda memiliki beberapa kantor, Anda pun akan perlu menyimpan sekumpulan data dari klien dalam masing-masing lokasi itu. Pengujian ini mengukur latensi, yang, dalam hal ini, merupakan nilai angka yang menjelaskan jumlah waktu antara klien mengirim permintaan ke Office 365 dan Office 365 merespons permintaan itu. Pengujian berasal dari dalam domain Anda pada komputer klien, dan ingin mengukur perjalanan pulang pergi dari dalam jaringan Anda, ke luar melalui titik keluar, melalui internet ke Office 365, dan kembali.

Ada beberapa cara untuk menangani titik keluar, dalam hal ini, server proksi. Anda bisa menelusuri dari 1 hingga 2 lalu 2 hingga 3, lalu menambahkan angka dalam milidetik untuk mendapatkan total akhir ke tepi jaringan Anda. Atau, Anda bisa mengonfigurasi koneksi untuk melewati proksi untuk alamat Office 365. Di jaringan yang lebih besar dengan firewall, proksi terbalik, atau kombinasi dari keduanya, Anda mungkin perlu membuat pengecualian pada server proksi yang akan memungkinkan lalu lintas lewat untuk banyak URL. Untuk mendapatkan daftar titik akhir yang digunakan oleh Office 365, lihat URL dan rentang alamat IP Office 365. Jika Anda memiliki proksi yang mengautentikasi, mulailah dengan menguji pengecualian untuk yang berikut ini:

  • Ports 80 dan 443

  • TCP dan HTTP

  • Koneksi yang keluar ke salah satu dari ini URL ini:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Semua pengguna perlu diperbolehkan mengakses alamat tersebut tanpa gangguan atau autentikasi proksi. Pada jaringan yang lebih kecil, Anda harus menambahkan alamat tersebut ke daftar lewati proksi di browser web Anda.

Untuk menambahkan alamat tersebut ke daftar lewati proksi Anda di Internet Explorer, masuk ke Alat > Opsi Internet > Koneksi > Pengaturan LAN > Tingkat Lanjut. Tab tingkat lanjut juga merupakan tempat Anda akan menemukan server proksi dan port server proksi Anda. Anda mungkin perlu mengklik kotak centang Gunakan server proksi untuk LAN Anda untuk mengakses tombol Tingkat Lanjut. Ada baiknya Anda memastikan bahwa Lewati server proksi untuk alamat lokal dicentang. Setelah mengklik Tingkat Lanjut, Anda akan melihat sebuah kotak teks di mana Anda bisa memasukkan pengecualian. Pisahkan URL wildcard yang tercantum di atas menggunakan titik dua, misalnya:

*.microsoftonline.com; *.sharepoint.com

Begitu Anda melewati proksi, Anda akan bisa menggunakan ping atau PsPing secara langsung di OURL ffice 365. Langkah berikutnya adalah menguji ping outlook.office365.com. Atau, jika Anda menggunakan PsPing atau alat lain yang akan memungkinkan Anda memasukkan nomor port ke perintah, PsPing terhadap portal.microsoftonline.com:443 untuk melihat rata-rata waktu perjalanan pulang pergi dalam milidetik.

Waktu perjalanan pulang pergi, atau RTT (Round Trip Time), adalah sebuah nilai angka yang mengukur berapa lama yang dibutuhkan untuk mengirim permintaan HTTP ke server seperti outlook.office365.com dan mendapatkan respons kembali yang mengakui bahwa server mengetahui bahwa Anda melakukannya. Anda kadang akan melihat ini disingkat menjadi RTT. Ini semestinya merupakan jumlah waktu yang singkat.

Anda harus menggunakan PSPing atau alat lain yang tidak menggunakan paket ICMP yang diblokir oleh Office 365 untuk melakukan pengujian ini.

Cara menggunakan PsPing untuk mendapatkan perjalanan pulang pergi keseluruhan dalam milidetik secara langsung dari URL Office 365

  1. Jalankan prompt perintah tinggi dengan menyelesaikan langkah-langkah berikut ini:

    1. Klik Mulai.

    2. Dalam kotak Mulai Pencarian , ketik cmd, lalu tekan CTRL+SHIFT+ENTER.

    3. Jika kotak dialog Kontrol Akun Pengguna muncul, konfirmasi bahwa tindakan yang ditampilkannya adalah apa yang Anda inginkan, lalu klik Lanjutkan.

  2. Navigasi ke folder tempat alat (dalam kasus ini PsPing) diinstal dan uji URL Office 365 berikut ini:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      Perintah PSPing masuk ke microsoft-my.sharepoint.com port 443.

Pastikan menyertakan nomor port 443. Ingat bahwa Office 365 bekerja pada saluran terenkripsi. Jika melakukan PsPing tanpa nomor port, permintaan akan gagal. Begitu sudah mem-ping daftar pendek Anda, lihat Waktu rata-rata dalam milidetik (ms). Itulah yang perlu Anda catat!

Grafik yang memperlihatkan ilustrasi klien keproksi PSPing dengan waktu perjalanan 2,8 milidetik.

Jika Anda belum terbiasa dengan lewati proksi, dan lebih memilih melakukan berbagai hal langkah demi langkah, Anda perlu terlebih dahulu mengetahui nama server proksi Anda. Di Internet Explorer masuk ke Alat > Opsi Internet > Koneksi > Pengaturan LAN > Tingkat Lanjut. Tab Tingkat Lanjut adalah tempat Anda akan melihat server proksi tercantum. Ping server proksi di prompt perintah dengan menyelesaikan tugas ini:

Untuk mengirimkan ping ke server proksi tersebut dan mendapatkan nilai perjalanan pulang pergi dalam milidetik untuk tahap 1 hingga 2

  1. Jalankan prompt perintah tinggi dengan menyelesaikan langkah-langkah berikut ini:

    1. Klik Mulai.

    2. Dalam kotak Mulai Pencarian , ketik cmd, lalu tekan CTRL+SHIFT+ENTER.

    3. Jika kotak dialog Kontrol Akun Pengguna muncul, konfirmasi bahwa tindakan yang ditampilkannya adalah apa yang Anda inginkan, lalu klik Lanjutkan.

  2. Ketik ping <nama server proksi yang digunakan browser Anda, atau alamat IP server proksi> lalu tekan ENTER. Jika Anda memiliki PsPing, atau beberapa alat lain yang terinstal, Anda bisa memilih menggunakan alat itu.

    Perintah Anda mungkin terlihat seperti salah satu contoh ini:

    • 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

  3. Saat penelusuran berhenti mengirimkan paket pengujian, Anda akan mendapatkan ringkasan kecil yang mencantumkan rata-rata dalam milidetik, dan itulah nilai yang Anda cari. Ambil cuplikan layar perintah itu dan simpan menggunakan menggunakan konvensi penamaan universal. Pada titik ini, mengisi diagram dengan nilai juga akan membantu.

Mungkin Anda sudah melakukan penelusuran di pagi hari, dan klien Anda dapat mengakses proksi (atau jalan keluar server keluar apa pun menuju internet) dengan cepat. Dalam kasus ini, angka Anda mungkin terlihat seperti ini:

Grafik yang memperlihatkan waktu perjalanan dari klien ke proksi dari 2,8 milidetik.

Jika komputer klien Anda merupakan salah satu dari beberapa komputer klien dengan akses ke proksi atau server (keluar), Anda bisa menjalankan leg berikutnya dengan menyambungkan ke komputer itu dari jarak jauh, menjalankan prompt perintah untuk PsPing ke URL Office 365 dari sana. Jika Anda tidak memiliki akses ke komputer itu, Anda bisa menghubungi petugas jaringan Anda untuk mendapatkan bantuan terkait leg berikutnya dan mendapatkan angka persis dengan cara itu. Jika itu tidak memungkin, lakukan PsPing terhadap URL Office 365 dimaksud dan bandingkan dengan waktu PsPing atau Ping erhadap server proksi Anda.

Misalnya, jika Anda memiliki 51,84 milidetik dari klien ke URL Office 365, dan Anda memiliki 2,8 milidetik dari klien ke proksi (atau titik keluar), maka Anda memiliki 49,04 milidetik dari titik keluar ke Office 365. Demikian pula, jika Anda memiliki 12,25 milidetik PSPing dari klien ke proksi selama puncak hari, dan 62,01 milidetik dari klien ke URL Office 365, maka nilai proksi rata-rata untuk titik keluar ke URL Office 365 adalah 49,76 milidetik.

Grafik tambahan yang memperlihatkan ping dalam milidetik dari klien ke proksi di samping klien ke Office 365 sehingga nilai dapat dikurangi.

Dalam hal pemecahan masalah, Anda mungkin menemukan sesuatu yang menarik dalam memelihara baseline tersebut. Misalnya, jika Anda menemukan bahwa Anda biasanya memiliki sekitar 40 hingga 59 milidetik latensi dari proksi atau titik keluar ke URL Office 365, dan menjalankan klien ke proksi atau latensi titik keluar sekitar 3 hingga 7 milidetik (bergantung pada jumlah lalu lintas jaringan yang Anda lihat selama waktu di hari itu), maka Anda akan mengetahui ada sesuatu yang bermasalah jika tiga baseline klien ke proksi atau titik akhir memperlihatkan latensi 45 milidetik.

Metode tingkat lanjut

Jika Anda benar-benar ingin mengetahui apa yang terjadi dengan permintaan Internet Anda ke Office 365, Anda perlu membiasakan diri dengan penelusuran jaringan. Tidak masalah alat mana yang lebih Anda sukai untuk penelusuran ini, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, alat Developer Dashboard, atau alat lain pun bisa sepanjang alat itu bisa merekam dan memfilter lalu lintas jaringan. Anda akan melihat dalam bagian ini bahwa penting untuk menjalankan lebih dari satu alat ini untuk mendapatkan gambaran masalah yang lebih lengkap. Saat Anda melakukan pengujian, beberapa alat ini juga bertindak sebagai proksi dengan sendirinya. Alat-alat yang digunakan dalam artikel yang menyertai, Rencana pemecahan masalah kinerja untuk Office 365, mencakup Netmon 3.4, HTTPWatch, atau Wireshark.

Menjalankan baseline kinerja adalah bagian sederhana metode ini, dan banyak-langkahnya sama seperti saat Anda memecahkan masalah kinerja. Metode yang lebih canggih dalam membuat baselines untuk kinerja mengharuskan Anda melakukan dan menyimpan penelusuran jaringan. Sebagian besar dari contoh-contoh di dalam artikel ini menggunakan SharePoint Online, tapi Anda harus mengembangkan daftar umum tindakan di seluruh layanan Office 365 langganan Anda untuk diuji dan dicatat. Berikut ini adalah contoh baseline:

  • Daftar baseline untuk SPO - Langkah 1: Telusuri halaman beranda situs web SPO dan lakukan penelusuran jaringan. Menyimpan penelusuran.

  • Daftar baseline untuk SPO - Langkah 2: Cari istilah (seperti nama perusahaan Anda) melalui Pencarian Perusahaan dan lakukan jaringan. Menyimpan penelusuran.

  • Daftar baseline untuk SPO - Langkah 3: Unggah file besar ke pustaka dokumen SharePoint Online dan lakukan penelusuran jaringan. Menyimpan penelusuran.

  • Daftar baseline untuk SPO - Langkah 4: Telusuri halaman beranda situs web OneDrive dan lakukan penelusuran jaringan. Menyimpan penelusuran.

Daftar ini harus menyertakan tindakan umum paling penting yang diambil pengguna terhadap SharePoint Online. Perhatikan bahwa langkah terakhir, untuk menelusuri dengan masuk ke OneDrive for Business, mengembangkan perbandingan antara muatan halaman beranda SharePoint Online (yang sering dikustomisasi menurut perusahaan) dan halaman beranda OneDrive for Business, yang jarang dikustomisasi. Ini adalah pengujian yang sangat mendasar menyangkut lambatnya pemuatan situs SharePoint Online. Anda bisa mengembangkan sebuah catatan perbedaan ini ke dalam pengujian.

Jika Anda berada di tengah-tengah masalah kinerja, banyak dari langkah-langkahnya yang sama dengan saat melakukan baseline. Penelusuran jaringan menjadi sangat penting, jadi kita akan menangani cara melakukan penelusuran penting berikutnya.

Untuk mengatasi masalah kinerja, sekarang, Anda perlu akan melakukan penelusuran pada saat Anda mengalami masalah kinerja. Anda perlu memiliki alat tepat yang tersedia untuk mengumpulkan log, dan Anda memerlukan rencana tindakan, yaitu, daftar tindakan pemecahan masalah untuk mengumpulkan informasi terbaik sebisa Anda. Hal pertama yang perlu dilakukan adalah mencatat tanggal dan waktu pengujian sehingga file bisa disimpan dalam folder yang mencerminkan waktu. Berikutnya, persempit langkah-langkah masalah itu sendiri. Ini adalah langkah-langkah persis yang akan Anda gunakan untuk menguji. Jangan lupa dasar-dasarnya: jika masalahnya hanya dengan Outlook, pastikan untuk mencatat bahwa masalah perilaku terjadi hanya pada satu layanan Office 365. Mempersempit lingkup masalah ini akan membantu Anda fokus pada sesuatu yang bisa Anda atasi.

Lihat Juga

Mengelola titik akhir Office 365

Kembangkan keterampilan Anda
Jelajahi pelatihan
Dapatkan fitur baru terlebih dahulu
Gabung ke Office Insiders

Apakah informasi ini bermanfaat?

Terima kasih atas umpan balik Anda!

Terima kasih atas umpan balik Anda! Sepertinya menghubungkan Anda ke salah satu agen dukungan Office kami akan sangat membantu.

×