6 AY PEŞİN −28% · 1 YIL PEŞİN −50%Planları karşılaştır
PrivacyNodes
UYGULAMA OPERASYONLARI

Yeniden boyutlandırmadan önce bir yavaş isteği izleyin

Yeniden üretilebilir yavaş bir işlemle ve yığın genelindeki zamanlamasıyla başlayın. Yüksek yanıt süresi tek başına VPS'i darboğaz olarak tanımlamaz. Sınırlı bir kanıt kümesi toplayın, bir hipotezi test edin ve değiştirdikten sonra aynı iş yükünü karşılaştırın.

PrivacyNodes mühendislik notları · İncelendi · 3 dk okuma

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ışı.

Örnek zamanlama, kaydedilmiş bir olay değil
AralıkİşlemSoru
0–40 msYönlendirme ve yetkilendirmeBu test hesabı için olağan mı?
40–640 msVeritabanı sınırıHavuz beklemesi, kilit beklemesi veya yürütme?
640–940 msDış zenginleştirmeBağlantı, yanıt veya yeniden deneme?
940–1,020 msSerileştirmeYü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.