Performans verimliliği denetim listesi

performans verimliliği, iş yükünüzün kullanıcı tarafından bu kullanıcılara yapılan talepleri verimli bir şekilde ölçeklendirme yeteneği ve Microsoft Azure Well-Architected çerçevesininbir bütün tarzına ait olduğu bir yöntemdir. Uygulama mimarinizi performans verimliliği açısından gözden geçirmek için bu denetim listesini kullanın.

Uygulama tasarımı

İş yükünü bölümleyin. İşlemin parçalarını, ayrık ve birleştirilebilir olacak şekilde tasarlayın. Her parçanın boyutunu en aza indirirken, kaygıları ayırma ve tek sorumluluk prensibi için olağan kuralları takip edin. Bu, bileşen bölümlerinin her bir işlem birimini (bir rol veya veritabanı sunucusu gibi) en üst düzeye çıkaran şekilde dağıtılmasını sağlar. Ayrıca, belirli kaynakların örneklerini ekleyerek uygulamayı ölçeklendirmeyi kolaylaştırır. Karmaşık etki alanları için bir mikro hizmet mimarisinibenimseme seçeneğini göz önünde bulundurun.

Ölçeklendirme Için tasarlayın. Ölçeklendirme, uygulamaların, kuyrukların ve kullandıkları diğer hizmetlerin sayısını artırarak ve azaltarak uygulamaların değişken yüküne tepki vermesini sağlar. Ancak, uygulama bu şekilde göz önünde bulundurularak tasarlanmalıdır. Örneğin, isteğin herhangi bir örneğe yönlendirilmesine izin vermek için, uygulamanın ve kullandığı hizmetlerin durum bilgisiz olması gerekir. Bu Ayrıca, belirli örneklerin eklenmesini veya kaldırılmasını geçerli kullanıcıların olumsuz etkilemesini önler. Ayrıca, eklenen ve kaldırılan örneklerin yapılandırma veya yeniden algılanması da uygulamanız gerekir, böylece uygulamadaki kod gerekli yönlendirmeyi gerçekleştirebilir. Örneğin, bir Web uygulaması istekleri çalışan rollerinde çalışan arka plan hizmetlerine yönlendirmek için hepsini bir kez deneme yaklaşımında bir dizi kuyruğu kullanabilir. Web uygulaması, istekleri başarıyla yönlendirmek ve uygulamadaki yükü dengelemek için sıra sayısında yapılan değişiklikleri algılayabilmelidir.

Birim olarak ölçeklendirin. Büyüme sağlamak için ek kaynaklar planlayın. Her kaynak için, üst ölçekleme sınırlarını öğrenin ve bu limitlerin ötesine geçmek için parçalama veya ayrıştırma kullanın. Sistem için ölçek birimlerini iyi tanımlanmış kaynak kümeleri bakımından belirler. Bu, genişleme işlemlerini daha kolay hale getirir ve uygulamanın, genel sistemin bazı bir bölümünde kaynak eksikliği nedeniyle uygulanan sınırlamalar aracılığıyla olumsuz etkiyle daha düşük bir etkiye neden olur. Örneğin x tane web ve çalışan rolü eklemek için, bu rollerin oluşturduğu ek iş yükünü işleyecek y tane ek kuyruk ve z tane depolama hesabı gerekebilir. Bu nedenle, bir ölçek birimi x Web ve çalışan rolleri, y kuyrukları ve z depolama hesaplarından oluşabilir. Bir veya daha fazla ölçek birimi ekleyerek daha kolay ölçeklendirilecek şekilde uygulamaları tasarlayın. Ölçek birimleri dağıtmak için dağıtım damgaları modelini kullanmayı düşünün.

İstemci benzeşimi kullanmaktan kaçının. Mümkün olduğunda, uygulamanın benzeşim gerektirmediğinden emin olun. İstekler bu nedenle herhangi bir örneğe yönlendirilebilir ve örnek sayısı ilgisiz olur. Bu Ayrıca, her kullanıcı için durum bilgilerini depolamanın, almanın ve korumanın yükünü ortadan kaldırır.

Platform otomatik ölçeklendirme özelliklerinin avantajlarından yararlanın. Barındırma platformu, Azure otomatik ölçeklendirme gibi bir otomatik ölçeklendirme özelliğini desteklediğinde, yerleşik mekanizmanın gereksinimlerinizi karşılayamadığı sürece özel veya üçüncü taraf mekanizmalarına tercih edilir. Bir başlangıç gecikmesi olmadan kaynakların kullanılabilir olduğundan emin olmak için mümkün olduğunda zamanlanmış ölçekleme kurallarını kullanın, ancak isteğe bağlı olarak, talep üzerine beklenmedik değişikliklerle ve bu kurallara uygun şekilde otomatik ölçeklendirme ekleyin. Otomatik ölçeklendirmeyi ayarlamak ve kurallara özel sayaçlar eklemek için klasik dağıtım modelindeki otomatik ölçeklendirme işlemlerini kullanabilirsiniz. Daha fazla bilgi için bkz. Otomatik ölçeklendirme Kılavuzu.

CPU yoğun ve g/ç kullanımı yoğun görevleri arka plan görevleri olarak boşaltma. Bir hizmete yönelik bir isteğin çalıştırılması veya artışlarını devralarak önemli kaynaklar olması bekleniyorsa, bu istek için işlemeyi ayrı bir göreve devretmek. Bu görevleri yürütmek için çalışan rollerini veya arka plan işlerini (barındırma platformuna bağlı olarak) kullanın. Bu strateji, hizmetin diğer istekleri almaya ve yanıt vermeye devam etmesine olanak sağlar. Daha fazla bilgi için arka plan işleri Kılavuzu' na bakın.

İş yükünü arka plan görevleri Için dağıtın. Birçok arka plan görevi olduğunda veya görevler önemli ölçüde zaman veya kaynak gerektirdiğinde, çalışmayı birden çok işlem birimi (örneğin, çalışan rolleri veya arka plan işleri) arasında yayın. Olası bir çözüm için bkz. rekabet tüketicileri.

Paylaşılan bir şey mimarisine doğru geçmeyi düşünün. Paylaşılan bir işlem temelli olmayan bir mimari, tek bir çekişme noktası olmayan bağımsız, kendi kendine yeterli düğümleri (örneğin, paylaşılan hizmetler veya depolama) kullanır. Teorik olarak, bir sistem neredeyse sonsuza kadar ölçeklendirebilirler. Tamamen paylaşılan bir yaklaşım genellikle çoğu uygulama için pratik olmasa da, daha iyi ölçeklenebilirlik için tasarlamak üzere fırsatlar sağlayabilir. Örneğin, sunucu tarafı oturum durumu, istemci benzeşimi ve veri bölümleme kullanımını önleme, paylaşılan bir işlem temelli bir mimariye doğru taşınmanın iyi örnekleridir.

Veri yönetimi

Veri bölümleme kullanın. verileri birden çok veritabanına ve veritabanı sunucusuna bölün ya da uygulamayı, bu bölümlemeyi saydam olarak sağlayabilen veri depolama hizmetlerini kullanacak şekilde tasarlayın (örnek Azure SQL Veritabanı elastik veritabanı ve Azure tablo depolama). Bu yaklaşım performansı en üst düzeye çıkarmaya ve daha kolay ölçeklendirilmesine yardımcı olabilir. Yatay, dikey ve işlevsel gibi farklı bölümleme teknikleri vardır. Daha fazla sorgu performansı, daha basit ölçeklenebilirlik, daha esnek yönetim, daha iyi kullanılabilirlik ve mağaza türü tutabileceği verilerle eşleştirmek için bunların bir birleşimini kullanabilirsiniz. Ayrıca, farklı veri türleri için farklı türlerde veri deposu kullanmayı göz önünde bulundurun, türleri belirli veri türleri için en iyi duruma getirilmiş hale göre seçebilirsiniz. Bu, tablo depolama, belge veritabanı veya bir sütun ailesi veri deposunun, ya da yerine bir ilişkisel veritabanının kullanılmasıyla birlikte olabilir. Daha fazla bilgi için bkz. veri bölümleme kılavuzu.

Nihai tutarlılık Için tasarlayın. Nihai tutarlılık, birden çok depo genelinde bölümlenmiş ilgili verileri eşitlemeniz için gereken süreyi azaltarak veya kaldırarak ölçeklenebilirliği artırır. Bu maliyet, veriler her zaman okunmadığınızda tutarlı değildir ve bazı yazma işlemleri çakışmalara neden olabilir. Nihai tutarlılık, aynı verilerin sık okunduğunu ancak seyrek yazıldığı durumlar için idealdir. Daha fazla bilgi için bkz. veri tutarlılığı temel bilgileri.

Bileşenler ve hizmetler arasındaki geveze etkileşimleri azaltın. Bir uygulamaya birden çok çağrı yapmak için gerekli olan etkileşimleri tasarlamaktan kaçının (her biri küçük miktarda veri döndüren), verilerin tümünü döndürebilen tek bir çağrı yerine. Mümkün olduğunda, çağrı fark eden gecikme süresine sahip bir hizmete veya bileşene geldiğinde, birkaç ilgili işlemi tek bir istekte birleştirin. Bu, performansı izlemenizi ve karmaşık işlemleri iyileştirmenizi kolaylaştırır. Örneğin, karmaşık mantığı kapsüllemek için veritabanlarında saklı yordamları kullanın ve gidiş dönüş sayısını ve kaynak kilitlemeyi azaltın.

Yüksek hız veri yazmaları için yükü seviyeden sonra kuyrukları kullanın. Bir hizmet için talepte, bu hizmeti tahmin edebilir ve hatalara yol açabilir. Bunu engellemek için kuyruk tabanlı yük dengeleme modeliniuygulamayı düşünün. Bir görev ve çağırdığı bir hizmet arasında arabellek görevi gören bir kuyruk kullanın. Bu, aksi halde hizmetin başarısız olmasına ya da görevin zaman aşımına başlamasına neden olabilecek aralıklı ağır yükleri sorunsuz bir şekilde kullanabilir.

Veri deposundaki yükü en aza indirin. Veri deposu genellikle bir işlem performans sorunu, maliyetli bir kaynaktır ve genellikle ölçeklendirilmesi kolay bir işlemdir. Mümkün olduğunda, veri deposundan mantığı kaldırın (XML belgelerini veya JSON nesnelerini işleme gibi) ve uygulama içinde işlem gerçekleştirin. Örneğin, XML veritabanına (depolama için donuk bir dize olarak değil) geçiş yapmak yerine, XML 'i uygulama katmanında serileştirme veya serisini kaldırma ve veri deposuna yerel bir biçimde geçirme. Uygulamanın veri deposundan ölçeğini genişletmek genellikle çok daha kolaydır, bu nedenle uygulama içinde mümkün olduğunca yoğun işlem yoğunluğu gerektiren işlemenin çoğunu yapmayı denemeniz gerekir.

Alınan veri hacmini en aza indirin. Sütunları belirterek ve satırları seçmek için ölçütleri kullanarak yalnızca ihtiyacınız olan verileri alın. Tablo değeri parametreleri ve uygun yalıtım düzeyi kullanımını yapın. Gereksiz verileri almayı önlemek için varlık etiketleri gibi mekanizmalar kullanın.

Ön belleğe alma kararlılığı. Veri üreten veya teslim eden kaynakların ve hizmetlerin yükünü azaltmak için mümkün olan her yerde önbelleğe alma özelliğini kullanın. Önbelleğe Alma, genellikle görece statik olan veya elde etmek için önemli işlemler gerektiren verilere uygundur. Önbelleğe Alma, veri erişimi ve kullanıcı arabirimi oluşturma da dahil olmak üzere, uygulamanın her katmanında uygun olan tüm düzeylerde gerçekleşmelidir. Daha fazla bilgi için bkz. Önbelleğe Alma Kılavuzu.

Veri büyüme ve bekletme işleme. Bir uygulama tarafından depolanan veri miktarı zaman içinde artar. Bu büyüme, uygulama aktarım hızını ve performansı etkileyen depolama maliyetlerinin yanı sıra verilere erişirken gecikme süresini de artırır. Artık erişilemeyen eski verilerden bazılarını düzenli olarak arşivlemek veya erişim gecikmesi daha yüksek olsa da daha fazla maliyetli olan uzun süreli depolamaya seyrek erişimli verileri taşımak mümkün olabilir.

Etkin ikili biçimi kullanarak veri aktarımı nesneleri (DTOs) iyileştirin. DTOs, bir uygulamanın katmanları çok kez geçirilir. Boyutunu en aza indirmek, kaynakların ve ağın yükünü azaltır. Bununla birlikte, verileri, kullanıldığı her konumdaki gerekli biçime dönüştürme iş yüküyle dengeleyin. Bir bileşenin kolay yeniden kullanılmasını sağlamak için maksimum birlikte çalışabilirliğe sahip bir biçim benimseyin.

Önbellek denetimi ayarlayın. İşlem yükünü en aza indirmek için, mümkün olduğunda çıktı önbelleği veya parça önbelleği kullanmak üzere uygulamayı tasarlayın ve yapılandırın.

İstemci tarafı önbelleğe almayı etkinleştirin. Web uygulamaları, Önbelleğe alınabilecek içerikte önbellek ayarlarını etkinleştirmelidir. Bu, varsayılan olarak genellikle devre dışıdır. Proxy sunucularda ve istemcilerde içeriğin önbelleğe alınmasını sağlamak için sunucuyu uygun önbellek denetim üst bilgilerini sunacak şekilde yapılandırın.

uygulamanın yükünü azaltmak için azure blob depolama ve azure Content Delivery Network kullanın. BLOB depolama alanında görüntüler, kaynaklar, betikler ve stil sayfaları gibi statik veya görece statik ortak içeriği depolamayı düşünün. Bu yaklaşım, her istek için bu içeriğin dinamik olarak oluşturulmasına neden olan yük uygulamasını sizi maliyetinden kurtarır. ayrıca, bu içeriği önbelleğe almak ve istemcilere iletmek için Content Delivery Network kullanmayı göz önünde bulundurun. Content Delivery Network kullanmak, içerik bir Content Delivery Network önbelleği içeren coğrafi olarak en yakın veri merkezinden teslim edildiğinden, istemcideki performansı iyileştirebilir. daha fazla bilgi için Content Delivery Network kılavuzabakın.

SQL sorguları ve dizinleri iyileştirin ve ayarlayın. bazı T-SQL deyimleri veya yapıları, bir saklı yordamda kodu en iyi duruma getirerek azalabilecek performansa olumsuz bir etkiye sahip olabilir. Örneğin, DateTime türlerini bir DateTime değişmez değeriyle karşılaştırmadan önce bir varchar öğesine dönüştürmekten kaçının . Bunun yerine tarih/saat karşılaştırma işlevlerini kullanın. Ayrıca, uygun dizinlerin olmaması sorgu yürütmeyi yavaşlatır. Bir nesne/ilişkisel eşleme çerçevesi kullanıyorsanız, nasıl çalıştığını ve veri erişim katmanının performansını nasıl etkileyeceğini anlayın. Daha fazla bilgi için bkz. sorgu ayarlama.

Verileri normalleştirmeyi düşünün. Veri normalleştirme, çoğaltmaya ve tutarsızlığa engel olmaya yardımcı olur. Ancak, birden çok dizini sürdürmek, bilgi tutarlılığını denetlemek, küçük veri öbeklerine birden çok erişim gerçekleştirmek ve verileri yeniden birleştirmek için tabloları birleştirmek, performansı etkileyebilecek bir ek yük getirir. Veri deposundaki yükü azaltmak için bazı ek depolama birimi ve yineleme kabul edilebilir olup olmadığını göz önünde bulundurun. Ayrıca, uygulamanın kendisinin (genellikle ölçeklendirilmesi daha kolay), veri deposundaki yükü azaltmak için bilgi tutarlılığı yönetme gibi görevleri yerine getirmek için ne olduğunu de göz önünde bulundurun. Daha fazla bilgi için bkz. veri bölümleme kılavuzu.

Uygulama

Performans kötü düzenlerini gözden geçirin. Bir uygulama basınca göre olduğunda ölçeklenebilirlik sorunlarına neden olabilecek yaygın uygulamalar için bkz. bulut uygulamaları Için performans kötü desenleri .

Zaman uyumsuz çağrılar kullanın. G/ç veya ağ bant genişliği ile sınırlı olabilecek ya da çağrı yapan iş parçacığını kilitlememek için fark edilebilir bir gecikme süresi olan kaynaklara veya hizmetlere erişirken mümkün olduğunda zaman uyumsuz kod kullanın.

Kaynakları kilitlemeden kaçının ve bunun yerine iyimser bir yaklaşım kullanın. Yetersiz gecikme süresine sahip olan depolama veya diğer hizmetler gibi kaynaklara erişimi hiçbir şekilde kilitlemez, çünkü bu önemli performans nedeniyle oluşur. Depolama birimine yazma gibi eşzamanlı işlemleri yönetmek için her zaman iyimser yaklaşımları kullanın. Çakışmaları yönetmek için depolama katmanının özelliklerini kullanın. Dağıtılmış uygulamalarda, veriler yalnızca en sonunda tutarlı olabilir.

Yüksek gecikme ve düşük bant genişliği ağları üzerinde yüksek oranda sıkıştırılabilir verileri sıkıştırın. Bir Web uygulamasındaki çoğu durumda, uygulama tarafından oluşturulan ve ağ üzerinden geçirilen en büyük veri hacmi istemci isteklerine HTTP yanıtlarıdır. HTTP sıkıştırması, özellikle statik içerik için bu önemli ölçüde azaltabilirler. Bu, maliyeti azaltabilir ve ağdaki yükü azaltır, ancak dinamik içeriğin sıkıştırılması sunucuda fractionally daha yüksek bir yük uygular. Diğer, daha Genelleştirilmiş ortamlarda, veri sıkıştırma, aktarılan verilerin hacmini azaltabilir ve aktarım süresini ve maliyetlerini en aza indirir, ancak sıkıştırma ve açma işlemi ek yüke neden olur. Bu nedenle, sıkıştırma yalnızca performansta bir kanıtlanabilir kazancı olduğunda kullanılmalıdır. JSON veya ikili kodlamalar gibi diğer serileştirme yöntemleri, performans üzerinde daha az etkilenirken yük boyutunu azaltabilir, ancak XML bunu artırabilir.

Bağlantıların ve kaynakların kullanımda olduğu süreyi en aza indirin. Yalnızca kullanmanız gereken sürece bağlantıları ve kaynakları saklayın. Örneğin, bağlantıları en geç şekilde açın ve mümkün olan en kısa sürede bağlantı havuzuna geri döndürülmelerini sağlar. Kaynakları mümkün olduğunca geç alın ve mümkün olan en kısa sürede atın.

Gereken bağlantı sayısını en aza indirin. Hizmet bağlantıları artışlarını devralarak kaynakları. Gerekli olan sayıyı sınırlayın ve mümkün olan her durumda mevcut bağlantıların yeniden kullanıldığından emin olun. Örneğin, kimlik doğrulamasını gerçekleştirdikten sonra, kodu belirli bir kimlik olarak çalıştırmak için uygun olan kimliğe bürünme özelliğini kullanın. Bu, bağlantıları yeniden kullanarak bağlantı havuzunun en iyi şekilde kullanılmasını sağlamaya yardımcı olabilir.

Ağ kullanımını iyileştirmek için istekleri toplu halde gönderin. Örneğin, bir kuyruğa erişirken iletileri toplu olarak gönderin ve okuyun ve depolama ya da önbelleğe erişirken Batch olarak birden çok okuma veya yazma işlemi gerçekleştirin. Bu, ağ genelindeki çağrı sayısını azaltarak hizmetlerin ve veri depolarının verimliliğini en üst düzeye çıkarmaya yardımcı olabilir.

Mümkün olduğunca sunucu tarafı oturum durumunu depolamak için bir gereksinimden kaçının . Sunucu tarafı oturum durumu yönetimi genellikle istemci benzeşimi gerektirir (diğer bir deyişle, her isteği aynı sunucu örneğine yönlendirme), bu da sistemin ölçeklenmesi olanağını etkiler. İdeal olarak, kullandıkları sunuculara göre istemcileri durum bilgisiz olacak şekilde tasarlamanız gerekir. Ancak, uygulamanın oturum durumunu koruması gerekiyorsa, uygulamanın tüm örneklerinin erişebileceği dağıtılmış bir sunucu tarafı önbelleğinde, hassas verileri veya istemci başına verileri büyük hacimlerini depolayın.

Tablo depolama şemalarını iyileştirin. Tablo ve sütun adlarının Azure Tablo depolaması gibi her sorguyla geçirilmesi ve işlenmesi gereken tablo depoları kullanıldığında, bu yükü azaltmak için daha kısa adlar kullanmayı düşünün. Ancak, aşırı sıkıştırma adlarını kullanarak okunabilirliği veya yönetilebilirliği femayın.

Dağıtım sırasında veya uygulama başlangıcında kaynak bağımlılıkları oluşturun. Bir kaynağın varlığını test eden ve mevcut değilse kaynağı oluşturan yöntemlere yinelenen çağrılar yapmaktan kaçının. cloudtable. createifnotexists ve cloudqueue. createifnotexists gibi yöntemler Azure Depolama istemci kitaplığında bu düzene uyun. Bu yöntemler, her bir depolama tablosuna veya depolama kuyruğuna erişmeden önce çağrılırsa önemli ölçüde yük getirir. Yerine

• Uygulama dağıtıldığında veya ilk kez başlatıldığında gerekli kaynakları oluşturun (bir Web veya çalışan rolü için başlangıç kodundaki her kaynak için Createıfnotexists 'e tek bir çağrı kabul edilebilir). Ancak, kodunuz mevcut olmayan bir kaynağa erişmeyi denediğinde oluşabilecek özel durumları işlediğinizden emin olun. Bu durumlarda, özel durumu günlüğe kaydedin ve muhtemelen bir kaynağın eksik olduğu bir işleci uyarır.
• Bazı durumlarda, özel durum işleme kodunun bir parçası olarak eksik kaynağı oluşturmak uygun olabilir. Ancak, kaynağın var olmayan bir programlama hatası (örneğin, yanlış yazılmış bir kaynak adı) veya başka bir altyapı düzeyinde sorun olduğunu kanıtlamak için bu yaklaşımı dikkatli benimsemelisiniz.

Hafif çerçeveleri kullanın. Kaynak kullanımını, yürütme süresini ve uygulamadaki genel yükü en aza indirmek için kullandığınız API 'Leri ve çerçeveleri dikkatle seçin. örneğin, hizmet isteklerini işlemek için Web apı 'sinin kullanılması, uygulama ayak izini azaltabilir ve yürütme hızını artırabilir, ancak Windows Communication Foundation ek özellikleri gereken gelişmiş senaryolar için uygun olmayabilir.

Hizmet hesabı sayısını en aza Indirmenizi göz önünde bulundurun. Örneğin, bağlantılara sınır uygulayan kaynaklara veya hizmetlere erişmek için belirli bir hesap kullanın veya daha az bağlantı gerçekleştiği yerde daha iyi gerçekleştirin. Bu yaklaşım veritabanları gibi hizmetler için ortaktır, ancak özgün kullanıcının kimliğine bürünmesi nedeniyle işlemleri doğru şekilde denetleme yeteneğini etkileyebilir.

Geliştirme sırasında performans profili oluşturma ve yük testi gerçekleştirme , test yordamlarının bir parçası olarak ve uygulamanın gerçekleştirdiğinden ve ölçeklendirilirken emin olmak için son sürümden önce. Bu test, üretim platformuyla aynı türde donanımda ve üretimde karşınıza çıkacak veri ve Kullanıcı yüklerine sahip olmalıdır. Daha fazla bilgi için bkz. bulut hizmetinin performansını test etme.