Beklenen sonucu net olan bir istek seçin
Örnek bir rapor uç noktası için rota desenini, yaklaşık veri boyutunu, kimlik doğrulama bağlamını ve arka plan işi oluşturup oluşturmadığını kaydedin. Bir test hesabı ve temsili arındırılmış veri kullanın. Belirteçleri, müşteri tanımlayıcılarını veya tam istek gövdelerini bir olay notuna kopyalamayın.
İlk istek başlatma maliyetini tekrarlanan kararlı durum davranışından ayırın. UTC penceresini ve sürüm revizyonunu kaydedin. Tüm rotaların mı yavaş olduğunu, yalnızca büyük raporların mı etkilendiğini yoksa gecikmenin tek bir dış bağımlılığı mı izlediğini belirleyin. Bu ayrımlar, bir sonraki ölçümü ilgisiz metriklerin geniş bir toplamından daha faydalı kılar.
Çift saymadan bir zaman çizelgesi oluşturun
OpenTelemetry izleri, hizmet sınırları boyunca yayılan bağlam aracılığıyla ilgili span'ları birbirine bağlar. Yalnızca zaman damgalarını eşleştirmek yeterli değildir. İç içe eşzamanlı span'lar ve paralel çağrılar çakışabilir. Eşzamansız alt öğeler ana öğelerinden daha uzun yaşayabilir, bu nedenle her span süresini toplamak geçen süreyi çift sayabilir. İsteğin ne zaman tamamlandığını belirleyen işlemleri izleyin.
Teknik referans: OpenTelemetry izleri · OpenTelemetry span bitiş davranışı.
| Aralık | İşlem | Soru |
|---|---|---|
| 0–40 ms | Yönlendirme ve yetkilendirme | Bu test hesabı için olağan mı? |
| 40–640 ms | Veritabanı sınırı | Havuz beklemesi, kilit beklemesi veya yürütme? |
| 640–940 ms | Dış zenginleştirme | Bağlantı, yanıt veya yeniden deneme? |
| 940–1,020 ms | Serileştirme | Yük ne kadar büyük? |
En büyük aralık, kök neden değil nerede inceleneceğini önerir. API'de ölçülen bir veritabanı aralığı, bir sorgu veritabanına ulaşmadan önce bağlantı beklemeyi içerebilir. Eksik telemetri de hiçbir işin gerçekleşmediğini kanıtlamaz; örneklemeyi ve enstrümantasyon kapsamını inceleyin.
Uygulama ve ana makine gözlemlerini ilişkilendirin
Aynı pencere için istek zamanlamalarını, hataları, veritabanı bağlantı kullanımını, kuyruk yaşını, CPU, bellek ve disk baskısını toplayın. Eşzamanlı yedeklemeleri, geçişleri veya sürümleri not edin. Tek bir kullanım ekran görüntüsü, isteği etkileyen ani artışı kaçırabilir.
Uygun saklama ve erişim denetimleriyle arındırılmış günlüklerde korelasyon kimliklerini ve zaman damgalarını kullanın. Ham sırlardan, müşteri yüklerinden ve sınırsız metrik etiketlerinden kaçının. Hipotez için gereken sınırı enstrümante edin ve ek yükü gözden geçirin. Yeni bir izleme aracısı da gözlemlenmeye değer bir değişikliktir.
Başka bir olaya yol açmadan sorguyu inceleyin
Önce sorgu şeklini, girdi boyutu özelliklerini ve bağlantı veya kilit beklemelerini belirleyin. PostgreSQL EXPLAIN bir plan tanımlar; EXPLAIN ANALYZE ifadeyi gerçekten yürütür ve enstrümantasyon ek yükü ekler. Bir yazma veriyi değiştirebilirken, pahalı bir okuma yine de yük oluşturur. İlk araştırma için yalıtılmış temsili bir veritabanı kullanın.
Planlayıcı maliyeti geçen milisaniye değildir. Küçük bir test tablosu, uygulamanın daha büyük veri kümesinden farklı bir plan üretebilir. İstatistikleri, dizinleri ve dağılımı gözden geçirin ve değiştirdikten sonra aynı sorgu şeklini karşılaştırın. Yalnızca zamanlama elde etmek için bilinmeyen bir yazmayı üretimde bir analiz komutuna yapıştırmayın.
Teknik referans: PostgreSQL EXPLAIN.
Tek bir değişikliğin neyi iyileştirmesi gerektiğini öngörün
Havuz beklemesi baskınsa, çalışan bağlantılarını veya bir bağlantıyı gereksiz yere tutan istekleri inceleyin. Sorgu yürütmesi baskınsa, planı ve istenen satırları inceleyin. Bir dış API baskınsa, zaman aşımlarını, yeniden denemeleri ve işin eşzamanlı olması gerekip gerekmediğini gözden geçirin. Serileştirme sırasında CPU doygunluğu farklı bir deneye işaret eder.
Bir öngörü yazın: dışa aktarma eşzamanlılığını azaltmak, dışa aktarmalar daha uzun sürerken API havuzu beklemesini azaltmalıdır. Bu, ödünleşimi ortaya koyar. Aynı istek karışımını yineleyin, gecikmeyi ve hataları karşılaştırın ve iyileştirmenin hatayı yalnızca giderek büyüyen bir kuyruğa taşımadığını denetleyin.
Sonucu ve belirsizliğini koruyun
Özgün gözlemi, test edilen değişikliği, karşılaştırma yöntemini ve kalan belirsizliği kaydedin. Kanıt hipotezle çelişiyorsa, uygun olduğunda yalıtılmış değişikliği geri alın ve başka bir sınırı araştırın. Açıklaması olmayan kalıcı ayar değişiklikleri biriktirmekten kaçının.
Ölçümler, ek tahsisin giderebileceği bir kaynak kısıtını tanımladığında yeniden boyutlandırın. Şunu kullanın: iş yükü bütçesi ve bir sürüm gerilemesini şurada yakalayın: olay özeti. Sonuç, vaat edilen bir gecikme veya sağlayıcı kıyaslaması değil, gerekçeli bir tanıdır.
Resmî referanslar
Bu makale için belgeler incelendi. Örnekler, bir PrivacyNodes sunucusunda test edilmiş komutlar değil, planlama alıştırmalarıdır. Yüklü sürümünüz için belgeleri kontrol edin.