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ı kurmak, gecikmeleri artırır ve çok daha fazla zaman alır mevcut tarafı yeniden kullanmak yerine her iki tarafta da en az iki kaynak olması gerekir. Daha az bağlantı kapatarak yeniden açılması gereken bağlantı sayısını azaltabilirsiniz.

Öncelikle, her yeni bağlantı için inceleyeceğiz. İsteğe bağlı bağlantılar kurduğumuz için kısa etkili teslim tarihleri vardır ve zaman aşımına uğrayan emin olun. Fazladan zaman aşımı olması hata oranını artırır ve bu da kısıtlanmasını sağlar.

İkinci olarak, birçok web sunucusu her bağlantı için özel bir çalışan iş parçacığı oluşturur yerleşik olarak bulunur. Bu, bağlantıyı kapatıp yeniden oluşturmak için sunucunun bir iş parçacığını kapatmalı ve silmeli, yeni bir iş parçacığı ayırmalı, çalıştırılabilir hale getirmelidir ve bağlantı durumunu oluşturun. Oldukça fazla ortadan kaldırır.

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

Bağlantı davranışını ayarlayarak başlayın. Çoğu sunucu varsayılanı, ve her birinin az sayıda müşteriye sahip olduğu, çok sayıda kabul edersiniz. Buna karşılık, RTB'de nispeten küçük bir makine havuzu, çok sayıda tarayıcı adına istek gönderir. Bu politikaların altında bağlantıları mümkün olduğunca çok kez yeniden kullanmak mantıklıdır. Biz şunları 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ı. 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 yeni web sitesi varsayılan "teklif yok" değerini döndüren kullanıcı arabirimi kodu arka uç durumunda yanıt zaman aşımı olması durumunda, kodun bağlantı. 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ı dengeli tutun

Authorized Buyers, teklif vereninizin sunucularına bağlanırsa bir proxy sunucusu üzerinden kurulan bağlantılar zamanla dengesiz hale gelebilir Authorized Buyers kullanıcıları, yalnızca proxy sunucunun IP adresini bilen her çağrıyı hangi teklif veren sunucusunun aldığını belirleyemiyor. 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, diğer açık bağlantılar o sırada ihtiyaç duyulmadığı için çoğunlukla boşta kalmaya devam ediyor. Farklı Authorized Buyers'ın trafik değişiklikleri, boştaki bağlantılar etkin ve etkin hale gelebilir boşta kalabilir. Bunlar, teklif veren sunucularınızda eşit olmayan yüklemelere neden olabilir büyük bir sıkıntı yaratabilir. Google, yoğun bağlantıları zaman içinde otomatik olarak yeniden dengelemek için 10.000 istekten sonra tüm bağlantıları kapatarak bu durumu önlemeye çalışır. Araç Çubuğu’nda trafiğin dengesiz hale geldiğini ya da atabileceğiniz başka adımlar da var:

1. Ön uç proxy'leri kullanıyorsanız arka ucu bağlantı başına bir kez yerine istek başına seçin.
2. Aşağıdaki şartları karşılıyorsanız bağlantı başına maksimum istek sayısı belirtin: bir donanım yük dengeleyici veya güvenlik duvarı aracılığıyla proxy eşleme, bağlantılar kurulduktan sonra sabitlenir. Google'ın zaten bağlantı başına 10.000 isteklik bir üst sınır belirtir, bu nedenle halen sıcak olduğunu fark ederseniz daha katı bir değer sağlamanız gerekir. bağlantılarınızın ortamınızda kümelenmesini sağlar. Örneğin Apache'te, MaxKeepAliveRequests değerini 5.000 olarak ayarlayın
3. Teklif verenin sunucularını istek oranlarını izleyecek ve bazılarını kapatacak şekilde yapılandırın sürekli olarak çok fazla istek işliyorsa elde etti.

Aşırı yüklenmekten kurtulun

İ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. Sonuç olarak, teklif vereninizin diğer kullanıcılara çok fazla trafik alıyor olabilir.

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ı basit olsa da bu teklif veren, en kötü teklifi verdiğinde aşırı yüklü. 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 devreye girer ve izin verilen açıklama metinlerinin sayısı önemli ölçüde azalır
• Gecikmeler iyileşmeye başlar ve böylece kısıtlama azalır
• Döngü tekrar başlar.

Bu teklif verenin gecikme grafiği, çok dik bir testere dişine benzemektedir desen. Alternatif olarak, sıraya alınmış istekler sunucunun sayfa ayırmaya başlamasına neden olur uzun vadeli yavaşlamaya neden olan başka bir şey yaptığında da gecikmeler en yoğun saatler sona erene kadar hiç iyileşmez. Bu da depresyona neden olur. (en yüksek dönemin tamamı boyunca) Her iki durumda da, daha az açıklama metni yapılır veya daha düşük bir değere ayarlanmasına kıyasla daha fazla yanıt verir.

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

Bu teklif veren, belirli bir orana kadar olan açıklama metinlerini kabul ediyor ve ardından geri dönmeye başlıyor hatalarının toplam sayısı. Bu işlem, dahili zaman aşımları aracılığıyla yapılabilir. bağlantı sıraya ekleme (Apache'de ListenBackLog tarafından kontrol edilir), kullanım veya gecikmeler fazla olduğunda olasılıksal bırakma modu uygulama veya başka bir mekanizma. Google %15'in üzerinde bir hata oranı gözlemlerse kısıtlamaya başlayacağı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üklenmede teklif yok" teklif veren

Bu teklif veren, belirli bir orana kadar olan açıklama metinlerini kabul ediyor ve ardından geri dönmeye başlıyor "teklif yok" yanıt veremiyor. "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ç makineleri tarafından emilir. Bu makineler yalnızca işleyebilecekleri trafiğin arka uçlara devam etmesine izin verir.

Bu teklif veren için gecikme grafiği, (yapay olarak) yoğun zamanlarda istek oranında paralellik kurmayı bırakır ve teklif içeren yanıtların oranı

"Aşırı yükleme hatası" "aşırı yüklenmede teklif yok" kendinize bir örnek verin:

• Kullanıcı arabirimlerinin temel hazırlığını fazladan yapın ve aşırı yük durumunda hata verecek şekilde ayarlayın. Bu, bir şekilde yanıt verebilecekleri bağlantı sayısını en üst düzeye çıkarmaya yardımcı olur.
• Aşırı yükleme sırasında hata verirken kullanıcı arabirimi makineleri bir hazır "no-bid" 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. Bu durumu, istek sayıları beklenenden çok daha yüksek olduğunda ön uç makinelerin "aşırı yükte hata" durumuna geri döndüğü "aşırı yükte 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.

Ping'lere yanıt verme

Teklif vereninizin bağlantı olmasa da ping isteklerine yanıt verebildiğinden emin olma hata ayıklama için şaşırtıcı derecede önemlidir. Google, teklif verenin durumu, bağlantı kapatma davranışı, gecikme ve diğer unsurların doğruluğunu kontrol etmek ve hata ayıklama yapmak için ping isteklerini kullanır. Ping istekleri aşağıdaki biçimdedir:

id: "7xd2P2M7K32d7F7Y50p631"

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

Ping isteğinin, beklediğinizin aksine reklam alanı içermediğini unutmayın. Ayrıca, yukarıda ayrıntılı olarak açıklandığı gibi, bir ping isteğine yanıt verdikten sonra bağlantıyı kapatmamanız gerekir.

Eşlemeyi 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, teklif vereninize ulaşmak için izlediği yolu optimize etmeye yardımcı olur. İlgili içeriği oluşturmak için kullanılan bağlantı uç noktaları aynı kalır ancak ara bağlantılar değişir. Bkz. Ayrıntılar için eşleme rehberine bakın. İlgili içeriği oluşturmak için kullanılan en iyi uygulama olarak düşünülmesini sağlayan sebepler ş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. Zaman bir sağlayıcıya ait olan, omurganın bir bölümünü geçecek ve çok sayıda eşleme bağlantısı varsa, seçilen bağlantı büyük olasılıkla gösterir. 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şın doğrudan eşleme anlaşması yapıldığında paketler her zaman bir eşleme bağlantısı ile 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 Google'da kalır bir iletişim ağı oluşturabilirsiniz. Gezinin büyük bir kısmını Google tarafından yönetilen platformda tutma altyapı, paketin düşük gecikmeli bir rota almasını sağlar ve çok fazla potansiyel değişkenlik gösterebilir.

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 bırakmasını ö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 yanıt olarak bir adresi veya adreslerin bir alt kümesini dağıtır uygulayabilir ve ardından bu yanıtta farklı bir şekilde gezinebilirsiniz.
2. DNS sunucusu her zaman aynı adres grubuyla yanıt verir ancak yanıttaki adreslerin sırası

İ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ği atlama denemeleri de tercih edilen sonuçları vermeyecektir.

İkinci teknik ise Google'dan bu yana yük dengelemeyi DNS yanıt listesinden rastgele bir IP adresi seçer. Böylece yanıtın önemi yoktur.

Teklif veren DNS değişikliği yaparsa Google, belirlemekte olup yenileme aralığı belirsizdir.