Temelleri ve performans geçmişini kullanarak Office 365 performansını ayarlama

Office 365 ile işletmeniz arasındaki bağlantının performansını denetlemenin birkaç basit yöntemi vardır. Bu yöntemler bağlantınız için kabaca bir temel oluşturmanıza olanak tanır. İstemci bilgisayar bağlantılarınızın performans geçmişini bilmek, sorunları ortaya çıkma aşamasında hemen belirlemenize ve problemleri tanımlayıp tahmin etmenize yardımcı olabilir.

Performans sorunları üzerinde çalışmaya alışkın değilseniz, bu makale şunun gibi bazı yaygın soruları değerlendirmenize yardımcı olacak şekilde hazırlanmıştır: Karşılaştığınız sorunun bir Office 365 hizmet olayı değil de performans sorunu olduğunu nereden anlarsınız? Uzun dönemde iyi bir performans için nasıl plan yapabilirsiniz? Performansı nasıl izleyebilirsiniz? Ekibiniz veya müşterileriniz Office 365 kullanırken yavaş performansla karşılaşıyorsa ve bu sorulardan herhangi birini merak ediyorsanız okumaya devam edin.

Önemli : Şu anda istemcinizle Office 365 arasında performans sorunu mu var?Office 365 için performans sorun giderme planı bölümünde özetlenen adımları uygulayın.

Office 365 performansı hakkında bilmeniz gerekenler

Office 365, yalnızca otomasyonla değil, aynı zamanda gerçek kişiler tarafından da sürekli izlenen, yüksek kapasiteli özel bir Microsoft ağı içinde yer alır. Office 365 bulutuna yönelik bakım görevinin bir kısmı, mümkün olan her yere performans ayarlama ve hızlandırma işlemlerini yerleştirmektir. Office 365 bulutu istemcilerinin İnternet üzerinden bağlanması gerektiğinden, Office 365 hizmetlerinde performans konusunda sürekli olarak ince ayarlamalar yapılır. Bulutta performans iyileştirmeleri hiçbir zaman tam olarak durmaz; bulutu sağlıklı ve hızlı tutma konusunda büyük bir deneyim birikimi vardır. Bulunduğunuz yerden Office 365’e bağlanırken performans sorunu yaşadığınızda bir Destek olayı başlatıp beklemeniz yeterli olmayacaktır. Bunun yerine, sorunu ‘ters yüz ederek’ araştırmaya başlamalısınız. Yani, araştırmaya ağınızın içinde başlayıp daha sonra Office 365'e yönelmelisiniz. Office 365 Desteği ile bir olay incelemesi açmadan önce veri toplayabilir ve karşılaştığınız sorunu inceleyebilecek ve belki de çözebilecek işlemler yapabilirsiniz.

Önemli : Kapasite planlamasını ve Office 365'teki sınırlamaları aklınızda bulundurun. Bu bilgiler performans sorunlarını çözmeye çalışırken bir adım önde olmanızı sağlar. Bu bağlantıdan Office 365 Platformu Hizmet Açıklaması’na erişebilirsiniz. Burası, Office 365 tarafından sunulan tüm hizmetlerin kendilerine ait Hizmet Açıklamalarına yönlendiren bağlantıları bulabileceğiniz bir merkezdir. Örneğin, SharePoint Online için standart sınırları görmeniz gerekirse, SharePoint Online Hizmet Açıklaması’na tıklayıp SharePoint Online Sınırları bölümüne bakabilirsiniz.

Sorun gidermeye başlarken, performansın değişken bir ölçeği olduğunu ve dolayısıyla amacın ideal bir performans değeri elde edip bunu korumak olmadığını unutmayın (performansın sabit olması gerektiğini düşünüyorsanız, çok sayıda kullanıcı barındırma veya büyük miktarda veri aktarma gibi ara sıra gerçekleştirilen yüksek bant genişlikli görevlerde zorlanabilirsiniz; böyle durumlar için performans etkilerini planlamanız gerekir). Performans hedefleriniz hakkında kabaca bir fikriniz olabilir ve olmalıdır da, ancak performans üzerinde rol oynayan birçok değişken vardır ve dolayısıyla performans da değişkendir. Değişkenlik, performansın yapısal özelliğidir.

Performans sorunlarını gidermek için belirli hedeflere ulaşmak ve bu rakamları sürekli olarak korumak yeterli değildir; asıl yapılması gereken, mevcut faaliyetleri tüm değişkenler ışığında geliştirmektir.

Tamam, bir performans sorunu nasıl görünür?

Öncelikle bir hizmet sorunu değil, gerçekten performans sorunu yaşadığınızdan emin olmanız gerekir. Performans sorunu, Office 365'teki bir hizmet sorunundan farklıdır. Bunları şu şekilde ayırt ederiz:

Office 365 hizmetinde sorunlar varsa, bu bir hizmet sorunudur. Office 365 yönetim merkezinde Geçerli sistem durumu altında kırmızı veya sarı simgeler görürsünüz ve Office 365’e bağlanan istemci bilgisayarlarda performansın yavaşladığını da fark edebilirsiniz. Örneğin Geçerli sistem durumu raporları kırmızı bir simge gösterirse ve Exchange’in yanında Araştırılıyor yazısını görürseniz, kuruluşunuzdaki birçok kişi sizi arayarak Exchange Online kullanan istemci posta kutularının iyi çalışmadığından şikayet edebilir. Böyle bir durumda, Exchange Online performansının Hizmet içindeki sorunlar nedeniyle düşmüş olma olasılığı yüksektir.

Durumu Hizmet Geri Yüklendi olarak görüntülenen Exchange dışında tüm iş yüklerinin yeşil renkte görüntülendiği Office 365 Hizmet Durumu panosu.

Bu noktada, Office 365 yöneticisi olarak sistemde yaptığımız bakımlardan haberdar olmak için Geçerli sistem durumunu denetlemeniz ve sık sık Ayrıntıları ve geçmişi görüntülemeniz gerekir. Geçerli sistem durumu panosu, sizi hizmetteki değişiklik ve sorunlardan haberdar etmek için kullanılır. Yöneticiden yöneticiye olmak üzere sistem durumu geçmişine yazılan notlar ve açıklamalar etkinizi artırmaya yardımcı olmak ve devam eden çalışma hakkında sizi bilgilendirmek için hazırlanır.

Exchange Online hizmetinin geri yüklendiğini ve nedenini açıklayan Office 365 hizmet durumu panosuna ait görüntü.

Hizmet etkinlikleri performansın yavaşlamasına neden olabilse de, bir performans sorunu hizmet olayı değildir. Bir performans sorunu şunlara benzer:

  • Office 365 yönetim merkezi Geçerli sistem durumu’nda hizmet için ne bildirilirse bildirilsin, bir performans sorunu ortaya çıkabilir.

  • Önceden görece daha iyi gerçekleşen bir davranış uzun zaman alır veya hiç tamamlanmaz.

  • Sorunu tekrarlatabilirsiniz veya en azından bir dizi adımı doğru şekilde uyguladığınızda gerçekleşeceğini bilirsiniz.

  • Sorun ara sıra ortaya çıkıyor olmakla birlikte, yine de sorun vardır; örneğin sabah saat 10:00 civarında, Office 365’e güvenilir şekilde bağlanamadığını söyleyen kullanıcılar arar ve aramalar öğlen civarı tamamen biter.

Bu muhtemelen sizin için tanıdık bir durumdur; belki de çok tanıdıktır. Bunun bir performans sorunu olduğunu anladıktan sonra, "Şimdi ne yapacaksınız?" sorusu gelir Bu makalenin kalan kısmı tam olarak bunu belirlemenize yardımcı olur.

Performans sorununu tanımlama ve test etme

Performans sorunları genellikle zaman içinde geliştiği için asıl sorunu tanımlamak zor olabilir. Günün kazananı olmak için iyi bir sorun açıklaması oluşturmanız, sorun bağlamında iyi bir fikir sahibi olmanız ve ardından tekrarlanabilir test adımları oluşturmanız gerekir. Aksi takdirde, hata sizin olmasa da kaybeden siz olabilirsiniz. Neden mi? Burada, yeterli bilgi sağlamayan sorun açıklamalarına bazı örnekler verilmiştir:

  • Eskiden Gelen kutumdan Takvimime geçerken farkına bile varmıyordum, şimdiyse kahve molası versem yeridir. Eskiden olduğu gibi çalışmasını sağlayabilir misiniz?

  • Dosyalarımı SharePoint Online’a yüklemem sonsuza dek sürüyor. Neden öğleden sonra yavaş da, diğer zamanlarda hızlı? Hızlı olamaz mı?

Yukarıdaki sorun açıklamalarından kaynaklanan bazı büyük güçlükler vardır. Özellikle, aşağıdakiler gibi, ilgilenmeyi gerektiren çok sayıda ikilem varsa:

  • Gelen kutusu ile Takvim arasında geçişin önceden dizüstü bilgisayarda nasıl olduğu belirsizdir.

  • Kullanıcı "Hızlı olamaz mı" derken, "hızlıdan" kasıt nedir?

  • "Sonsuza dek" derken ne kadar uzun demek istiyor? Birkaç saniye veya birkaç dakika mı, yoksa kullanıcı yemeğe çıkıp döndükten 10 dakika sonra mı bitiyor?

Tüm bunlar yöneticinin ve sorun giderenin birçok ayrıntıyı fark edemeyeceği sorun açıklamalarıdır. Örneğin sorun gerçekleşmeye başladığında; Kullanıcı evden çalışıyordur ve yalnızca ev ağındayken yavaş geçişle karşılaşıyordur; Kullanıcı istemcide yoğun RAM kullanan birçok uygulama kullanıyordur veya kullanıcı eski bir işletim sistemi çalıştırıyordur ya da son güncelleştirmeleri çalıştırmamıştır.

Kullanıcı bir performans sorunu bildirdiğinde, toplanması gereken birçok bilgi vardır. Bu bilgileri toplamak sorunun kapsamını belirlemenin veya araştırılmasının bir parçasıdır. Aşağıda, performans sorununuz hakkında bilgi toplamak için kullanabileceğiniz temel bir kapsam belirleme listesi verilmiştir. Bu liste geniş kapsamlı değildir, ancak kendi başınıza başlamak için uygun bir yerdir:

  • Sorun hangi tarihte ve günün veya gecenin hangi saatinde gerçekleşti?

  • Ne tür bir istemci bilgisayar kullanıyordunuz ve iş ağınıza nasıl bağlantı kurulmuştu (VPN, kablolu, kablosuz)?

  • Uzaktan mı çalışıyordunuz, Office'te miydiniz?

  • Başka bir bilgisayarda da aynı eylemleri denediniz ve aynı davranışı görürsünüz mü?

  • Gerçekleştirdiğiniz eylemleri not alabilmeniz için, soruna neden olan adımları takip edin.

  • Performans saniye veya dakika olarak ne kadar yavaş?

  • Dünyanın neresinde bulunuyorsunuz?

Bu sorulardan bazıları diğerlerinden daha belirgindir. Çoğu kişi, bir sorun gidericinin sorunu yeniden oluşturmak üzere tam adımlara ihtiyacı olduğunu anlar. Sonuçta, neyin yanlış olduğunu başka nasıl kaydedebilir ve sorunun çözüldüğünü başka nasıl test edebilirsiniz? Daha az belirgin olan şeyler, "Sorunu hangi tarihte ve saatte gördünüz?" ve "Dünyanın neresindesiniz?" gibi, birlikte kullanılabilecek bilgilerdir. Kullanıcının ne zaman çalıştığına bağlı olarak, birkaç saatlik zaman farkı, şirket ağınızın bölümlerinde devam eden bir bakım olduğu anlamına gelebilir. Örneğin şirketinizde hem SharePoint Online’da hem de Şirket içi SharePoint Server 2013 kopyasında arama dizinlerini sorgulayan bir karma SharePoint Araması gibi karma bir uygulama varsa, şirket içi grupta güncelleştirmeler gerçekleştiriliyor olabilir. Şirketinizin tamamı bulutta ise, sistem bakımı ağ donanımı ekleyip kaldırmayı, şirket çapında güncelleştirmeler yapmayı ya da DNS’te veya diğer çekirdek altyapıda değişiklikler yapmayı kapsayabilir.

Bir performans sorunu giderirken gibi, bu biraz olay yeri incelemeye benzer, kanıtlardan yola çıkarak sonuca varmak için hassas ve dikkatli olmanız gerekir. Bunu yapmak için, kanıt toplayarak bir iyi sorun açıklaması elde etmeniz gerekir. Bilgisayarın bağlamı, kullanıcının bağlamı, sorunun ne zaman başladığı ve performans sorununu ortaya çıkaran tam adımlar buna dahildir. Bu sorun açıklaması notlarınızın en başında olmalı ve orada kalmalıdır. Çözüm üzerinde çalıştıktan sonra sorun açıklamasının yeniden üzerinden geçerek gerçekleştirmiş olduğunuz işlemlerin sorunu çözüp çözmediğini test edip kanıtlamak için gerekli adımları atmış olursunuz. Bu, orada görevinizin ne zaman tamamlandığını bilmek açısından önemlidir.

Performansın yüksek olduğu zamanlarda nasıl göründüğünü biliyor musunuz?

Şansınız yoksa kimse bilmiyordur. Hiç kimsede sayılar yoktur. Yani kimse şu basit soruları yanıtlayamaz; "Önceden Office 365’te bir Gelen Kutusunu çalışır duruma getirmek yaklaşık kaç saniye sürüyordu?" veya "Yöneticilerin bir Lync Online toplantısı yapması ne kadar sürüyordu?" Bu birçok şirket için yaygın bir senaryodur.

Burada eksik olan Performans temel taban çizgileridir.

Taban çizgisi performansınız için size bir bağlam sunar. Şirketinizin gereksinimlerine dayalı olarak sık sık bir taban çizgisi almanız gerekir. Daha büyük bir şirketseniz, Operasyon ekibiniz zaten şirket içi ortamınız için taban çizgileri alıyor olabilir. Örneğin her ayın ilk Pazartesi günü tüm Exchange sunucularınızda ve üçüncü Pazartesi günü tüm SharePoint sunucularınızda düzeltme ekleri uyguluyorsanız Operasyon ekibinizde muhtemelen, düzeltme eki uygulandıktan sonra çalıştırılan ve kritik görevlerin çalışır durumda olduğunu kanıtlayan bir görevler ve senaryolar listesi olur. Örneğin Gelen Kutusunu açma, Gönder/Al’a tıklama ve klasörlerin güncelleştirildiğinden emin olma veya SharePoint’te sitenin ana sayfasına gitme, kurumsal Arama sayfasına gitme ve sonuç veren aramalar yapma.

Uygulamalarınız Office 365’teyse, alabileceğiniz en bilinen bazı taban çizgileri ağınız içindeki bir istemci bilgisayardan, çıkış noktasına veya ağdan çıkıp Office 365’e gittiğiniz noktaya kadar olan süreyi (mili saniye) ölçmektir. Araştırıp kaydedebileceğiniz bazı yararlı taban çizgileri şunlardır:

  • İstemci bilgisayarlarınızla çıkış noktanız (örneğin proxy sunucunuz) arasındaki cihazları tanımlayın.

    • Ortaya çıkan performans sorunlarına ilişkin bir bağlam (IP adresleri, cihazın türü, vb.) elde edebilmeniz için cihazlarınızı tanımanız gerekir.

    • Proxy sunucuları yaygın çıkış noktalarıdır, dolayısıyla web tarayıcınızı denetleyerek varsa hangi proxy sunucusunu kullanmaya ayarlandığını belirleyebilirsiniz.

    • Ağınızı keşfetmesi ve eşlemesi için üçüncü taraf araçlardan yararlanabilirsiniz, ancak cihazlarınızı tanımanın en güvenli yolu, ağ ekibinizin bir üyesine sormaktır.

  • İnternet servis sağlayıcınızı (ISS) tanımlayın, iletişim bilgilerini not alın ve kaç devreniz olduğunu ve ne kadar bant genişliğiniz olduğunu sorun.

  • Şirketiniz içinde, istemcinizle çıkış noktası arasındaki kaynakları tanımlayın veya ağ sorunlarını görüşmek üzere başvurulacak bir acil durum kişisi tanımlayın.

Aşağıda, araçlarla yapılacak basit bir sınamanın sizin için hesaplayabileceği bazı taban çizgileri verilmiştir:

  • İstemci bilgisayarınızdan çıkış noktanıza kadar olan mili saniye cinsinden süre

  • Çıkış noktanızdan Office 365’e kadar olan mili saniye cinsinden süre

  • Gözatma sırasında Office 365 URL’lerini çözümleyen sunucunun dünyadaki konumu

  • Mili saniye cinsinden ISS’nizin DNS çözümleme hızı, paket almadaki (ağ değişimi) tutarsızlıklar, yükleme ve indirme süreleri.

Bu adımları nasıl uygulayacağınızı bilmiyorsanız, bu makalede daha fazla ayrıntı bulabilirsiniz.

Taban çizgisi nedir?

Kötü gittiğinde etkisini bilirsiniz, ama geçmiş performans verilerinizi bilmezseniz, ne zaman ve ne kadar kötüleştiğine dair bir bağlama sahip olmak mümkün değildir. Dolayısıyla bir taban çizgisi olmadan, bulmacayı çözmek için en önemli ipucu olan bulmaca kutusundaki resmi kaçırmış olursunuz. Performans sorunlarını gidermede, bir karşılaştırma noktasına ihtiyacınız vardır. Basit performans taban çizgileri almak zor değildir. Operasyon ekibiniz bir takvime göre bunları yapmakla görevlendirilebilir. Örneğin bağlantınızın aşağıdaki gibi olduğunu varsayalım:

İstemci, proxy ve Office 365 bulutun görüntülendiği temel ağ grafiği.

Buna göre ağ ekibinizle birlikte kontrol ettiniz ve şirketinizden İnternet için bir proxy sunucusu üzerinden çıkış yaptığınızı ve istemci bilgisayarınızın buluta gönderdiği tüm istekleri bu proxy’nin işlediğini gördünüz. Bu durumda, bağlantınızın aradaki tüm cihazları listeleyen basitleştirilmiş bir sürümünü çizmeniz gerekir. Şimdi de, çıkış noktası (İnternet için ağınızdan ayrıldığınız yer) olan istemciyle Office 365 bulutu arasına, performansı test etmek için kullanabileceğiniz araçlar ekleyin.

İstemci, proxy ve bulut içeren temel ağ ve araç önerileri PSPing, TraceTCP ve ağ izleme.

Performans verilerini bulmak için gereksinim duyduğunuz uzmanlık seviyesi nedeniyle, seçenekler Basit ve Gelişmiş olarak listelenmiştir. Ağ izleme, PsPing ve TraceTCP gibi komut satırı araçları çalıştırmaya göre çok zaman alır. Bu iki komut satırı aracının seçilmiş olmasının nedeni, Office 365 tarafından engellenen ICMP paketleri kullanmamaları ve istemci bilgisayardan veya proxy sunucusundan (erişiminiz varsa) ayrılıp Office 365’e ulaşana kadar geçen süreyi mili saniye cinsinden vermeleridir. Bir bilgisayardan diğerine her sıçrama bir zaman değeri ile sonuçlanır ve bu da taban çizgileri için mükemmeldir! Ayrıca şu da önemlidir ki, bu komut satırı araçları, komuta bir bağlantı noktası numarası eklemenize izin verir ve Office 365, Güvenli Yuva Katmanı ve Aktarım Katmanı Güvenliği (TLS ve SSL) tarafından kullanılan bağlantı noktası olan bağlantı noktası 443 üzerinden iletişim kurduğu için bu yararlı olur. Bununla birlikte, üçüncü taraflara ait diğer araçlar sizin durumunuz için daha iyi bir çözüm olabilir. Microsoft, bu araçların tümünü desteklemez ve bu durumda herhangi bir nedenle PsPing ve TraceTCP aracının çalışmasını sağlayamazsanız Netmon gibi bir araçla ağ izleme işlemine geçin.

Taban çizgilerini iş saatlerinden önce, sonra tekrar yoğun kullanım sırasında ve tekrar saatler sonra alabilirsiniz. Buna göre, sonunda biraz buna benzer bir klasör yapısına sahip olabilirsiniz:

Performans verilerinizi klasörler halinde düzenleme yöntemi sunan grafik.

Ayrıca, dosyalarınız için bir adlandırma kuralı da belirlemeniz gerekir. İşte birkaç örnek:

  • 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

Bunu yapmanın birçok çeşitli yolları vardır, ancak <dateTime><what's happening in the test> biçimini kullanmak iyi bir başlangıç olur. Bu konuda gayretli olmak, daha sona sorunları gidermeye çalışırken size çok yardımcı olur. Daha sonra şöyle diyebilirsiniz: "8 Şubat’ta iki izleme kaydettim, biri iyi, diğeri kötü performans gösterdiği için bunları karşılaştırabiliriz". Bu sorun giderme için son derece yararlı olur.

Geçmiş taban çizgilerinizi tutmak için düzenli bir yol bulmanız gerekir. Bu örnekte, basit yöntemler üç komut satırı çıktısı üretmiştir ve sonuçlar ekran görüntüsü olarak toplanmıştır, ancak bunun yerine sizde ağ yakalama dosyaları da bulunabilir. Size en uygun yöntemi kullanın. Geçmiş taban çizgilerini depolayın ve çevrimiçi hizmetlerin davranışında değişiklik fark ettiğiniz noktada bunlara başvurun.

Neden pilot çalışma sırasında performans verileri toplanmalıdır?

Taban çizgileri hazırlamaya başlamak için, Office 365 hizmetinin pilot çalışması sırasındakinden daha iyi bir zaman yoktur. Ofisinizde binlerce, yüz binlerce kullanıcı veya beş, hatta çok daha az sayıda kullanıcı olabilir, ancak az sayıda kullanıcıyla bile performans dalgalanmalarını ölçmek üzere testler gerçekleştirebilirsiniz. Büyük bir şirket söz konusu olduğunda, Office 365 denemesi yapan birkaç yüz kullanıcıdan oluşan temsili bir örnek, birkaç bin kullanıcıya yansıtılabilir ve böylece gerçekleşmeden önce sorunların nerede ortaya çıkabileceğini bilirsiniz.

Pilot çalışma olmayıp herkesin birlikte hizmeti kullandığı küçük bir şirket söz konusu olduğunda, performansı kötü olan bir işlemde sorun gidermesi gerekebilecek herhangi birine gösterecek verileriniz olması için performans ölçülerini tutun. Örneğin daha önce çok çabuk olan orta büyüklükte bir grafiği karşıya yüklemek için gereken sürede bütün binayı dolaşabildiğinizi fark ederseniz.

Taban çizgilerini toplama

Tüm sorun giderme planları için en azından şunları tanımlamanız gerekir:

  • Kullanmakta olduğunuz istemci bilgisayar (bilgisayar veya cihazın türü, IP adresi ve soruna neden olan eylemler)

  • İstemci bilgisayarın dünya üzerindeki konumu (örneğin, bu kullanıcının ağa giden bir VPN’de olup olmadığı, uzaktan çalışıp çalışmadığı veya şirketinizin intranetinde olup olmadığı)

  • İstemci bilgisayarın ağınızda kullandığı çıkış noktası (trafiğin kuruluşunuzdan ISS veya İnternet'e çıkış noktası)

Ağınızın düzenini ağ yöneticisinden öğrenebilirsiniz. Küçük bir ağdaysanız, sizi İnternet’e bağlayan cihazlara bakın ve düzenle ilgili sorularınız varsa ISS’nizi arayın. Başvurabilmek için son düzenin bir grafiğini oluşturun.

Bu bölüm, basit komut satırı araçlarına ve yöntemlerine ve daha gelişmiş araç seçeneklerine bölünmüştür. Önce basit yöntemleri ele alacağız. Ancak, şu anda bir performans sorununuz varsa, gelişmiş yöntemlerle geçmeli ve örnek performans sorunlarını giderme eylem planını denemelisiniz.

Basit yöntemler

Bu basit yöntemlerin amacı Office 365 performansı hakkında bilinçli olmanız için, zaman içinde basit performans taban çizgilerini almayı, anlamayı ve uygun şekilde saklamayı öğrenmektir. Burada, daha önce gördüğünüz gibi çok basit bir diyagram verilmiştir:

İstemci, proxy ve bulut içeren temel ağ ve araç önerileri PSPing, TraceTCP ve ağ izleme.

Notlar : 

  • TraceTCP’nin bu ekran görüntüsünde yer almasının nedeni, bir isteğin işlenmesi için geçen süreyi mili saniye cinsinden göstermede ve isteğin hedef ulaşmak üzere bir bilgisayardan diğerine kaç sıçrama veya bağlantı geçtiğini göstermede yararlı bir araç olmasıdır. TraceTCP ayrıca sıçramalarda kullanılan sunucuların adlarını da verebilir ve bu Destek’teki Microsoft Office 365 sorun gidericileri için çok yararlı olabilir.

  • TraceTCP komutları aşağıdaki gibi çok basit olabilir:

  • tracetcp.exe outlook.office365.com:443

  • Bağlantı noktası numarasını komuta eklemeyi unutmayın!

  • TraceTCP ücretsiz olarak indirilir, ancak Wincap ile kullanılır. Wincap de Netmon tarafından kullanılan ve yüklenen bir araçtır. Netmon’u ayrıca gelişmiş yöntemler bölümünde de kullanırız.

Birden fazla ofisiniz varsa, bu konumların her birindeki bir istemciden de bir veri kümesi bulundurmanız gerekir. Bu sınama, burada Office 365’e istek gönderen bir istemciyle, isteğe yanıt veren Office 365 arasındaki süreyi tanımlayan bir sayı değeri olan gecikme süresini ölçer. Sınama etki alanınız içinde bir istemci bilgisayardan kaynaklanır ve ağınız içinde, bir çıkış noktasından, İnternet’te Office 365’e ve sonra geriye doğru gidiş dönüş süresini ölçmeye çalışır.

Bu durumda proxy sunucusu olan çıkış notasıyla ilgilenmenin birkaç yolu vardır. 1’den 2’ye ve sonra 2’den 3’e izleme yapabilir ve son bir toplam almak üzere ağınızın ucuna mili saniye cinsinden sayılar ekleyebilirsiniz. Veya bağlantıyı Office 365 adresleri için proxy’i atlayacak şekilde yapılandırabilirsiniz. Güvenlik duvarı, ters proxy veya her ikisinin birlikte bulunduğu daha büyük bir ağda, proxy sunucusunda trafiğin pek çok URL için geçmesine izin verecek özel durumlar oluşturmanız gerekebilir. Office 365 tarafından kullanılan uç noktaların listesi için bkz. Office 365 URL’leri ve IP adres aralıkları. Kimlik doğrulama proxy'niz varsa, aşağıdakiler için özel durumları test ederek başlayın:

  • 80 ve 443 bağlantı noktaları

  • TCP ve HTTP’ler

  • Şu URL'lerin herhangi birine giden bağlantılar:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Tüm kullanıcıların, herhangi bir proxy müdahalesi veya kimlik doğrulaması olmadan bu adreslere ulaşmalarına izin verilmesi gerekir. Daha küçük bir ağda, web tarayıcınızda bunları bu proxy atlama listesine eklemeniz gerekir.

Internet Explorer’da bunları proxy atlama listenize eklemek için, Araçlar > İnternet Seçenekleri> Bağlantılar > LAN ayarları > Gelişmiş’e gidin. Gelişmiş sekmesi ayrıca proxy sunucunuzu ve proxy sunucu bağlantı noktanızı bulacağınız yerdir. Advanced düğmesine ulaşmak için, Yerel ağınız için ara sunucu kullanın onay kutusuna tıklamanız gerekebilir. Yerel adresler için proxy sunucuyu atla seçeneğinin işaretli olduğundan emin olmanızda yarar vardır. Gelişmiş’e tıkladığınızda, özel durumları girebileceğiniz bir metin kutusu görürsünüz. Yukarıda listelenen joker karakter URL'leri noktalı virgüller ile ayırın; örneğin:

*.microsoftonline.com; *.sharepoint.com

Proxy’nizi atladıktan sonra, ping veya PsPing’i doğrudan bir Office 365 URL’sinde kullanabiliyor olmalısınız. Sonraki adım outlook.office365.com için ping sınaması yapmaktır. Ya da PsPing veya komutta bağlantı noktası numarası kullanmanıza izin veren başka bir araç kullanıyorsanız, ortalama gidiş dönüş süresini mili saniye cinsinden görmek için portal.microsoftonline.com:443 ile PsPing yapın.

Gidiş dönüş süresi veya RTT, outlook.office365.com gibi bir sunucuya HTTP isteği göndermenin ve sunucunun bunu yaptığınızı bildiğini gösteren bir yanıt almanın ne kadar sürdüğünü ölçen bir sayı değeridir. Bunu bazen RTT şeklinde kısaltılmış olarak görürsünüz. Bu, görece kısa bir süre olmalıdır.

Bu testi yapmak için PsPing kullanmanız veya Office 365 tarafından engellenen ICMP paketlerini kullanmayan başka bir araçtan yararlanmanız gerekir.

Doğrudan bir Office 365 URL’sinden mili saniye cinsinden genel bir gidiş dönüş süresi almak için PsPing kullanma

  1. Şu adımları tamamlayarak yükseltilmiş bir komut istemi çalıştırın:

    1. Başlat'a tıklayın.

    2. Arama Başlatkutusuna cmd yazıp CTRL+ÜST KRKT+ENTER tuşlarına basın.

    3. Kullanıcı Hesabı Denetimi iletişim kutusu görüntülenirse, görüntülediği eylemin istediğiniz eylem olduğunu kontrol edip Tamam’a tıklayın.

  2. Aracın (Bu durumda PsPing) yüklendiği klasöre gidin ve şu Office 365 URL'lerini test edin:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      microsoft-my.sharepoint.com bağlantı noktası 443’e giden PSPing komutu.

Bağlantı noktası numarası 443’ü komuta eklemeyi unutmayın. Office 365’in şifreli bir kanal üzerinde çalıştığını unutmayın. Bağlantı noktası numarası olmadan PsPing yaparsanız, isteğiniz başarısız olur. Kısa listenizde ping işlemi yaptıktan sonra, mili saniye olarak (ms) Ortalama süreye bakın. Kaydetmek istediğiniz budur!

İstemci ile proxy arasında 2,8 milisaniyelik bir gidiş dönüş süresine sahip PSPing’i gösteren grafik.

Proxy atlama işlemine alışkın değilseniz ve işlemleri adım adım yapmak istiyorsanız, önce proxy sunucunuzun adını bulmanız gerekir. Internet Explorer’da Araçlar > İnternet Seçenekleri > Bağlantılar > LAN ayarları > Gelişmiş’e gidin. Gelişmiş sekmesi, proxy sunucunuzun listelendiği yerdir. Bir komut isteminde şu görevi tamamlayarak bu proxy sunucusunda ping sınaması yapın:

Proxy sunucusunda ping yapmak ve aşama 1’den 2’ye mili saniye cinsinden bir gidiş dönüş değeri almak için

  1. Şu adımları tamamlayarak yükseltilmiş bir komut istemi çalıştırın:

    1. Başlat'a tıklayın.

    2. Arama Başlatkutusuna cmd yazıp CTRL+ÜST KRKT+ENTER tuşlarına basın.

    3. Kullanıcı Hesabı Denetimi iletişim kutusu görüntülenirse, görüntülediği eylemin istediğiniz eylem olduğunu kontrol edip Tamam’a tıklayın.

  2. ping <tarayıcınızın kullandığı proxy sunucusunun adını veya proxy sunucusunun IP adresini> yazıp ENTER tuşuna basın. PsPing veya başka bir araç yüklüyse, bu aracı kullanmayı da tercih edebilirsiniz.

    Komutunuz şu örneklerden birine benzeyebilir:

    • 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. İzleme işlemi test paketleri göndermeyi durdurduğunda, mili saniye cinsinden ortalama veren küçük bir liste görürsünüz ve aradığınız değer budur. İstemin ekran görüntüsünü alın ve adlandırma kuralınıza uygun şekilde kaydedin. Bu noktada, diyagramı değerle doldurmanıza da yardımcı olabilir.

Diyelim ki, sabah erken saatte bir izleme aldınız ve istemciniz proxy’e (veya İnternet’e çıkışta kullanılan herhangi bir çıkış sunucusuna) hızlı şekilde bağlanabiliyor. Bu durumda, numaralarınız buradaki gibi görünebilir:

Bir istemci ve proxy arasındaki 2,8 milisaniyelik gidiş dönüş süresini gösteren grafik.

İstemci bilgisayarınız proxy (veya çıkış) sunucusuna erişimi olan az sayıda bilgisayardan biriyse, bu bilgisayara uzaktan bağlanıp, buradan Office 365 URL’sine PsPing testi yapmak üzere komut istemini çalıştırarak testin sonraki aşamasını gerçekleştirebilirsiniz. Bu bilgisayara erişiminiz yoksa, sonraki aşamada yardım için ağ kaynaklarınızı başvurabilir ve böylece tam sayıları alabilirsiniz. Bu mümkün değilse, söz konusu Office 365 URL’si için PsPing testi yapın ve proxy sunucunuza karşı PsPing veya Ping süresiyle karşılaştırın.

Örneğin istemciden Office 365 URL’sine 51,84 mili saniye sonuç alıyor ve istemciden proxy sunucusuna (veya çıkış noktasına) 2,8 mili saniye sonuç alıyorsanız, erişim noktasından Office 365’e 49,04 mili saniye geçiyor demektir. Benzer şekilde, günün yoğun saatlerinde istemciden proxy sunucusuna 12,25 mili saniye ve istemciden Office 365 URL’sine 62,01 mili saniyelik PsPing alıyorsanız Office 365 URL’sin proxy çıkışınızın ortalama değeri 49,76 mili saniyedir.

Değerlerin çıkarılabilmesi için istemciden proxy’e ve istemciden Office 365’e gönderilen ping’i milisaniye cinsinden gösteren ek grafik.

Sorun giderme anlamında, bu taban çizgilerini saklayarak ilginç bir şey bulabilirsiniz. Örneğin proxy’den veya çıkış noktasından Office 365 URL’sine yaklaşık 40 ila 59 mili saniye ve bir istemciden proxy’ye veya çıkış noktasına yaklaşık 3 ila 7 mili saniye kadar gecikme olduğunu bulursanız (günün o saatinde gördüğünüz ağ trafiğine bağlıdır), son üç istemciden proxy’ye veya çıkış noktasına taban çizileri 45 mili saniye gecikme süresi gösterir.

Gelişmiş yöntemler

Office 365’e gönderdiğiniz İnternet isteklerinizde neler olup bittiğini gerçekten öğrenmek isterseniz, ağ izlemeleri hakkında bilgi sahibi olmanız gerekir. Bu izlemeler için hangi araçları kullandığınız fark etmez; HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Geliştirici Panosu aracı veya diğerleri, ağ trafiğini yakalayıp filtreleyebildikleri sürece işe yarar. Bu bölümde, soruna ilişkin daha ayrıntılı bir fikir edinmek için bu araçlardan birkaçını çalıştırmanın yararlı olacağını göreceksiniz. Test sırasında bu araçlardan bazıları, kendi haklarına sahip ara sunucular gibi davranır. Office 365 için performans sorunu giderme planı konulu yardım makalesinde Netmon 3.4, HTTPWatch veya WireShark gibi araçlar kullanılmıştır.

Performans taban çizisi almak bu yöntemin basit kısmıdır ve adımların bir çoğu performans sorunu giderirken uygulanan adımlarla aynıdır. Performans için taban çizisi oluşturmanın daha gelişmiş yöntemleri, ağ izleri alıp saklamanızı gerektirir. Bu makaledeki örneklerin çoğunda SharePoint Online kullanılmıştır, test etmek ve kaydetmek üzere abone olduğunuz Office 365 hizmetlerinde bir ortak eylemler listesi geliştirmeniz gerekir. Burada bir taban çizgisi örneği görülmektedir:

  • SPO için taban çizgisi listesi- 1. Adım: SPO Web sitesinin giriş sayfasına gidin ve ağ izleme yapın. İzlemeyi kaydedin.

  • SPO için taban çizgisi listesi- 2. Adım: Kurumsal Arama ile bir terim (örneğin şirketinizin adı) arayın ve ağ izleme işlemi gerçekleştirin. İzlemeyi kaydedin.

  • SPO için taban çizgisi listesi- 3. Adım: Bir SharePoint Online belge kitaplığına büyük bir dosya yükleyin ve ağ izleme işlemi gerçekleştirin. İzlemeyi kaydedin.

  • SPO için taban çizgisi listesi- 4. Adım: OneDrive web sitesinin giriş sayfasına gidin ve ağ izleme işlemi gerçekleştirin. İzlemeyi kaydedin.

Bu liste kullanıcıların SharePoint Online'a karşı gerçekleştirdiği en önemli ortak eylemleri içermelidir. Son adım olan OneDrive İş’e gidişi izleme adımının SharePoint Online giriş sayfasının yükü (çoğu zaman şirketler tarafından özelleştirilir) ile OneDrive İş giriş sayfası (nadiren özelleştirilir) arasında yerleşik bir karşılaştırma oluşturur. Yavaş yüklenen bir SharePoint Online sitesine sıra geldiğinde bu çok basit bir testtir. Testiniz içinde bu farkın kaydını oluşturabilirsiniz.

Bir performans sorununun ortasındaysanız, taban çizgisi alırken adımların çoğu aynıdır. Ağ izleri çok önemli hale gelir ve bu nedenle bundan sonra önemli izlerin nasıl alınacağını ele alacağız.

Bir performans sorunuyla başa çıkmak için, hemen şimdi performans sorunu yaşadığınız sırada bir izleme almanız gerekir. Günlükleri toplamak için hazırda uygun araçlarınız olması ve bir eylem planınız, yani elde edebildiğiniz en iyi bilgileri toplamak için yapılacak sorun giderme işlemlerinin listesi olması gerekir. Yapılacak ilk şey testin tarih ve saatini kaydetmektir; böylece dosyalar zamanlamayı gösteren bir klasöre kaydedilebilir. Ardından, sorunlu adımların kendisine doğru listeyi daraltın. Bunlar test etmek için kullanacağınız tam adımlardır. Temel bilgileri unutmayın: sorun yalnızca Outlook’taysa, sorunlu davranışın yalnızca bir Office 365 hizmetinde olduğundan emin olun. Bu sorunun kapsamı daraltmak, çözebileceğiniz bir şeye odaklanmanıza yardımcı olur.

Ayrıca Bkz:

Office 365 uç noktalarını yönetme

Yeteneklerinizi geliştirin
Eğitimleri keşfedin
Yeni özellikleri ilk olarak siz edinin
Office Insider Programına Katılın

Bu bilgi yararlı oldu mu?

Görüşleriniz için teşekkür ederiz!

Geri bildiriminiz için teşekkürler! Office destek temsilcilerimizden biriyle görüşmeniz yararlı olabilir.

×