GZT Uygulamaları için En İyi Uygulamalar

Bu kılavuzda, RTB protokolüne göre uygulama geliştirirken dikkate alınması gereken en iyi uygulamalar açıklanmaktadır.

Bağlantıları yönetme

Bağlantıları canlı tutun

Yeni bir bağlantı oluşturmak, gecikme sürelerini artırır ve mevcut bir bağlantıyı yeniden kullanmaktan çok daha fazla kaynak gerektirir. Daha az bağlantı kapatarak yeniden açılması gereken bağlantı sayısını azaltabilirsiniz.

Öncelikle, her yeni bağlantının kurulabilmesi için ek bir ağ gidiş dönüş işlemi gerekir. Bağlantıları isteğe bağlı olarak kurduğumuz için bağlantıdaki ilk istek daha kısa bir son tarihe sahiptir ve sonraki isteklerden daha fazla zaman aşımı olasılığı vardır. Ek zaman aşımları hata oranını artırır ve teklif vereninizin sınırlandırılmasına neden olabilir.

İkinci olarak, birçok web sunucusu kurulan her bağlantı için özel bir çalışan iş parçacığı oluşturur. Bu, bağlantıyı kapatıp yeniden oluşturmak için sunucunun bir iş parçacığını kapatıp atması, yeni bir iş parçacığı ayırması, çalıştırılabilir hale getirmesi ve bağlantı durumunu oluşturması, ardından isteği işlemesi gerektiği anlamına gelir. Bu, gereksiz çok fazla masraf demektir.

Bağlantıları kapatmaktan kaçının

Bağlantı davranışını ayarlayarak başlayın. Çoğu sunucu varsayılan ayarı, her biri az sayıda istek gönderen çok sayıda istemcinin bulunduğu ortamlar için özelleştirilmiştir. Buna karşılık, RTB'de nispeten küçük bir makine havuzu, çok sayıda tarayıcı adına istek gönderir. Bu koşullarda, bağlantıları mümkün olduğunca çok kez yeniden kullanmak mantıklıdır. Aşağıdakileri ayarlamanızı öneririz:

  • Boşta kalma zaman aşımı 2,5 dakikaya ayarlandı.
  • Bir bağlantıdaki maksimum istek sayısı, mümkün olan en yüksek değere ayarlanır.
  • RAM'inizin kaldırabileceği en yüksek değere kadar maksimum bağlantı sayısı. Bu sırada bağlantı sayısının bu değere çok yaklaşmadığından emin olun.

Örneğin, Apache'te bu, KeepAliveTimeout değerinin 150, MaxKeepAliveRequests değerinin sıfır ve MaxClients değerinin sunucu türüne bağlı bir değere ayarlanmasını gerektirir.

Bağlantı davranışınız ayarlandıktan sonra teklif veren kodunuzun bağlantıları gereksiz yere kapatmadığından da emin olmanız gerekir. Örneğin, arka uç hataları veya zaman aşımları durumunda varsayılan "teklif yok" yanıtı döndüren bir kullanıcı arabirimi kodunuz varsa kodun bağlantıyı kapatmadan yanıtını döndürdüğünden emin olun. Bu sayede, teklif vereninizin aşırı yüklenmesi durumunda bağlantıların kapanmaya başlaması ve zaman aşımı sayısının artması nedeniyle teklif vereninizin sınırlandırılması gibi durumları önleyebilirsiniz.

Bağlantıları dengede tutma

Authorized Buyers, teklif vereninizin sunucularına bir proxy sunucu üzerinden bağlanırsa Authorized Buyers yalnızca proxy sunucusunun IP adresini bildiğinden, her açıklama metnini hangi teklif veren sunucusunun aldığını belirleyemediği için bağlantılar zaman içinde dengesiz hale gelebilir. Yetkili Alıcı'lar bağlantı oluşturup kapattıkça ve teklif verenin sunucuları yeniden başlatıldıkça, her birine eşlenen bağlantıların sayısı oldukça değişken olabilir.

Bazı bağlantılar yoğun olarak kullanıldığında, o anda ihtiyaç duyulmadığı için açık olan diğer bağlantılar çoğunlukla boşta kalabilir. Yetkili Alıcı'ların trafiği değiştikçe, etkin olmayan bağlantılar etkin hale gelebilir ve etkin bağlantılar etkin olmayan hale gelebilir. Bağlantılar kötü bir şekilde gruplandırılırsa bu durum, teklif veren sunucularınızda dengesiz yüklere neden olabilir. Google, yoğun bağlantıların zaman içinde otomatik olarak yeniden dengelenmesi için 10.000 istekten sonra tüm bağlantıları kapatarak bu durumu önlemeye çalışır. Ortamınızda trafiğin dengesiz hale geldiğini hâlâ görüyorsanız uygulayabileceğiniz başka adımlar da vardır:

  1. Ön uç proxy'leri kullanıyorsanız arka ucu bağlantı başına bir kez yerine istek başına seçin.
  2. Bağlantıları bir donanım yük dengeleyici veya güvenlik duvarı üzerinden proxy'liyorsanız ve bağlantılar kurulduktan sonra eşleme sabitse bağlantı başına maksimum istek sayısını belirtin. Google'ın bağlantı başına 10.000 istek üst sınırı belirlediğini unutmayın. Bu nedenle, ortamınızda yoğun bağlantıların kümelendiğine dair bir durumla karşılaşırsanız daha katı bir değer sağlamanız yeterlidir. Örneğin Apache'te, MaxKeepAliveRequests değerini 5.000 olarak ayarlayın
  3. Teklif verenin sunucularını, istek oranlarını izleyecek ve benzerlerine kıyasla sürekli olarak çok fazla istek işliyorsa kendi bağlantılarının bir kısmını kapatacak şekilde yapılandırın.

Aşırı yüklemeyi sorunsuz şekilde yönetme

İdeal olarak kotalar, teklif vereninizin işleyebileceği tüm istekleri alabilmesi için yeterince yüksek ayarlanır ancak bundan fazlası olmaz. Uygulamada, kotaları optimum seviyelerde tutmak zor bir iştir ve çeşitli nedenlerle aşırı yüklenmeler meydana gelir: yoğun zamanlarda arka uç kapanır, trafik karışımı değişir ve her istek için daha fazla işlem yapılması gerekir veya kota değeri çok yüksek ayarlanır. Bu nedenle, teklif vereninizin çok fazla trafik geldiğinde nasıl davranacağını düşünmeniz faydalı olacaktır.

Bölgeler (özellikle Asya ile ABD Batı ve ABD Doğu ile ABD Batı arasında) arasındaki geçici trafik değişikliklerine (bir haftaya kadar) uyum sağlamak için 7 günlük zirve ile Ticaret Bölgesi başına QPS arasında% 15'lik bir pay bırakmanızı öneririz.

Ağır yükler altındaki davranış açısından teklif verenler üç geniş kategoriye ayrılır:

"Her şeye yanıt veren" teklif veren

Uygulaması kolay olsa da bu teklif veren, aşırı yüklendiği durumlarda en kötü performansı gösterir. Her ne olursa olsun gelen her teklif isteğine yanıt vermeye çalışır ve hemen yayınlanamayan isteklerini sıraya ekler. Bunun sonucunda genellikle şu senaryo ortaya çıkar:

  • İstek oranı arttıkça istek gecikmeleri de artar. Bu durum, tüm isteklerin zaman aşımına uğramasına neden olur.
  • Açıklama metni oranları zirveye yaklaştıkça gecikmeler de hızla artar.
  • Sınırlama uygulanır ve izin verilen açıklama metinlerinin sayısı önemli ölçüde azaltılır.
  • Gecikmeler düzelmeye başlar ve kısıtlama azaltılır.
  • Döngü tekrar başlar.

Bu teklif verenin gecikmesi grafiği, çok dik bir testere dişi desenine benziyor. Alternatif olarak, sıraya alınmış istekler sunucunun belleği sayfalamaya başlamasına veya uzun süreli yavaşlamaya neden olan başka bir işlem yapmasına neden olur. Ayrıca, yoğun saatler sona erene kadar gecikmeler hiç düzelmez. Bu da yoğun dönemin tamamında açıklama metni oranlarının düşmesine yol açar. Her iki durumda da, kota daha düşük bir değere ayarlanmış olsaydı yapılan veya yanıtlanan açıklama metinlerinin sayısı daha az olur.

"aşırı yükleme hatası" teklif vereni

Bu teklif veren, belirli bir orana kadar açıklama metinlerini kabul eder ve ardından bazı açıklama metinleri için hata döndürmeye başlar. Bu işlem, dahili zaman aşımları, bağlantı sırasını devre dışı bırakma (Apache'te ListenBackLog tarafından kontrol edilir), kullanım veya gecikmeler çok yüksek olduğunda olasılıksal bir bırakma modu uygulama veya başka bir mekanizma aracılığıyla yapılabilir. Google, %15'in üzerinde bir hata oranı gözlemlerse veri aktarımını yavaşlatmaya başlarız. "Her şeye yanıt veren" teklif verenin aksine bu teklif veren, "kayıplarını azaltır". Bu sayede, istek oranları düştüğünde hemen toparlanabilir.

Bu teklif verenin gecikmesi grafiği, aşırı yükleme sırasında kabul edilebilir maksimum oran civarında yerelleştirilmiş sığ bir testere dişi desenine benzer.

"Aşırı yükleme durumunda teklif yok" teklif vereni

Bu teklif veren, belirli bir orana kadar açıklama metinlerini kabul eder, ardından aşırı yüklenme durumunda "teklif yok" yanıtları döndürmeye başlar. "aşırı yükleme hatası" teklif verenine benzer şekilde, bu özellik birkaç şekilde uygulanabilir. Buradaki fark, Google'a hiçbir sinyal döndürülmediğinden açıklama metinlerinin hiçbir zaman azaltılmamasıdır. Aşırı yük, ön uç makineler tarafından emilir. Bu makineler yalnızca işleyebilecekleri trafiğin arka uçlara devam etmesine izin verir.

Bu teklif verenin gecikmesi grafiği, yoğun zamanlarda istek oranına paralelliği (yapay olarak) durduran bir plato ve teklif içeren yanıtların oranındaki karşılık gelen bir düşüşü gösterir.

"Aşırı yükleme durumunda hata" yaklaşımını "aşırı yükleme durumunda teklif verme" yaklaşımıyla aşağıdaki şekilde birleştirmenizi öneririz:

  • Bazı şekillerde yanıt verebilecekleri bağlantı sayısını en üst düzeye çıkarmak için ön uçları fazladan hazırlayın ve aşırı yüklenme durumunda hata verecek şekilde ayarlayın.
  • Aşırı yüklenme durumunda hata oluştuğunda, kullanıcı arabirimi makineleri hazır bir "teklif yok" yanıtı kullanabilir ve isteği ayrıştırması gerekmez.
  • Arka uçların durum denetimini uygulayın. Böylece, yeterli kapasitesi olmayan arka uçlar "teklif yok" yanıtı döndürür.

Bu sayede, aşırı yükün bir kısmı emilebilir ve arka uçlara, tam olarak kaldırabilecekleri sayıda isteğe yanıt verme şansı verilir. Bunu, istek sayıları beklenenden çok daha yüksek olduğunda ön uç makinelerin "aşırı yükleme durumunda hata" durumuna geri döndüğü "aşırı yükleme durumunda teklif yok" olarak düşünebilirsiniz.

"Her şeye yanıt veren" bir teklif vereniniz varsa bağlantı davranışını, aşırı yüklenmeyi reddedecek şekilde ayarlayarak "aşırı yüklendiğinde hata" veren bir teklif verene dönüştürmeyi düşünebilirsiniz. Bu, daha fazla hatanın döndürülmesine neden olsa da zaman aşımlarını azaltır ve sunucunun hiçbir isteğe yanıt veremez hale gelmesini önler.

Eşleme yapmayı düşünün

Ağ gecikmesini veya değişkenliğini azaltmanın bir diğer yolu da Google ile eşleme yapmaktır. Eşleme, trafiğin teklif vereninize ulaşmak için izlediği yolu optimize etmeye yardımcı olur. Bağlantı uç noktaları aynı kalır ancak ara bağlantılar değişir. Ayrıntılar için eşleme kılavuzuna bakın. Eşlemeyi en iyi uygulama olarak düşünmenin nedeni şu şekilde özetlenebilir:

  • İnternette, aktarma bağlantıları öncelikle "aktarıcı yönlendirme" aracılığıyla seçilir. Bu yöntem, ağı dışındaki en yakın bağlantıyı bulur ve paketi bu bağlantı üzerinden yönlendirir. Trafik, çok sayıda eşleme bağlantımız olan bir sağlayıcıya ait bir omurga bölümünü geçtiğinde, seçilen bağlantı büyük olasılıkla paketin başladığı yere yakın olur. Bu noktadan sonra paketin teklif verene giden rotası üzerinde hiçbir kontrolümüz yoktur. Bu nedenle, paket yolda diğer otonom sistemlere (ağlara) yönlendirilebilir.

  • Buna karşılık, doğrudan eşleme sözleşmesi olduğunda paketler her zaman bir eşleme bağlantısı üzerinden gönderilir. Paketin kaynağı ne olursa olsun, teklif verenin konumuna yakın olması gereken paylaşılan eşleme noktasına ulaşana kadar Google'ın sahip olduğu veya kiraladığı bağlantılardan geçer. Ters yolculuk, Google ağına kısa bir atlamayla başlar ve yolun geri kalanında Google ağında kalır. Seyahatin büyük kısmının Google tarafından yönetilen altyapıda tutulması, paketin düşük gecikmeli bir rota izlemesini sağlar ve olası çok fazla değişkenlikten kaçınır.

Statik DNS gönderme

Alıcıların her zaman Google'a tek bir statik DNS sonucu göndermesini ve trafik yayınını Google'a devretmesini öneririz.

Teklif verenler, dengeyi yüklemeye veya kullanılabilirliği yönetmeye çalışırken DNS sunucularında yaygın olarak kullanılan iki yöntem şunlardır:

  1. DNS sunucusu, bir sorguya yanıt olarak bir adres veya adres alt kümesi verir ve ardından bu yanıtı bir şekilde döndürür.
  2. DNS sunucusu her zaman aynı adres grubuyla yanıt verir ancak yanıttaki adreslerin sırasını değiştirir.

İlk teknik, yığının birden fazla seviyesinde çok fazla önbelleğe alma işlemi olduğu için yük dengeleme konusunda zayıftır. Ayrıca Google, DNS çözümleme süresini teklif verenden aldığı için önbelleğe alma işlemini atlama denemeleri de tercih edilen sonuçları vermeyecektir.

Google, DNS yanıtı listesinden rastgele bir IP adresi seçtiği için ikinci teknikte yük dengesi sağlanamaz. Bu nedenle, yanıttaki sıranın bir önemi yoktur.

Bir teklif veren DNS değişikliği yaparsa Google, DNS kayıtlarında ayarlanan TTL'yi(Geçerlilik Süresi) dikkate alır ancak yenileme aralığı belirsiz kalır.