GZT Uygulamaları için En İyi Uygulamalar

Bu kılavuzda, GZT Protokolü'ne göre uygulama geliştirirken göz önünde bulundurulması gereken en iyi uygulamalar açıklanmaktadır.

Bağlantıları yönetme

Bağlantıları canlı tutun

Yeni bağlantı kurmak, gecikmeleri artırır ve her iki tarafta da mevcut bir bağlantıyı yeniden kullanmaya kıyasla çok daha fazla kaynak gerektirir. Daha az bağlantıyı kapatarak tekrar açılması gereken bağlantı sayısını azaltabilirsiniz.

Öncelikle, her yeni bağlantının kurulması için fazladan bir ağ döngüsü gerekir. İsteğe bağlı bağlantılar kurduğumuz için bir bağlantıyla ilgili ilk isteğin geçerlilik süresi daha kısadır ve bu istek, sonraki isteklerden daha fazla zaman aşımına uğrar. Ek zaman aşımları hata oranını artırır. Bu durum, teklif vereninizin kısıtlanmasına neden olabilir.

İkinci olarak, birçok web sunucusu kurulan her bağlantı için özel bir çalışan iş parçacığı oluşturur. Yani, isteği işleme koymadan önce, bağlantıyı kapatıp yeniden oluşturmak için sunucunun bir iş parçacığını kapatıp silmesi, yeni bir iş parçacığı tahsis etmesi, çalıştırılabilir hale getirmesi ve bağlantı durumunu oluşturması gerekir. Bu da oldukça fazla gereksiz ek yük anlamına gelir.

Bağlantıları kapatmaktan kaçınma

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

  • 2,5 dakikaya boşta kalma zaman aşımı.
  • Mümkün olan en yüksek değere sahip bir bağlantıda maksimum istek sayısıdır.
  • RAM'inizin karşılayabileceği en yüksek değere yönelik maksimum bağlantı sayısı ve bağlantı sayısının bu değere çok fazla yaklaşmadığını doğrulamaya özen gösterin.

Örneğin Apache'de, sunucu türüne bağlı olarak KeepAliveTimeout değerinin 150, MaxKeepAliveRequests öğesinin sıfır ve MaxClients değerinin ayarlanması gerekir.

Bağlantı davranışınızı ayarladı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 bir "teklif yok" yanıtı döndüren kullanıcı arabirimi kodunuz varsa kodun bağlantıyı kapatmadan yanıtını döndürdüğünden emin olun. Böylece teklif vereninizin aşırı yüklenmesi, bağlantıların kapanmaya başlaması ve zaman aşımı sayısının artması durumunda teklif vereninizin kısıtlanmasına neden olur.

Bağlantıları dengeli tutun

Authorized Buyers, teklif vereninizin sunucularına bir proxy sunucu üzerinden bağlanırsa bağlantılar zaman içinde dengesiz hale gelebilir. Bunun nedeni, yalnızca proxy sunucunun IP adresini bilen Authorized Buyers'ın her bir açıklama metnini hangi teklif veren sunucusunun aldığını belirleyememesidir. Zaman içinde Authorized Buyers bağlantı kurup kapattığında ve teklif verenin sunucuları yeniden başlatıldıkça her biriyle eşlenen bağlantı sayısı son derece değişken hâle gelebilir.

Bazı bağlantılar yoğun bir şekilde kullanıldığında, o anda gerekli olmadıkları için açık olan diğer bağlantılar çoğunlukla boşta kalabilir. Authorized Buyers'ın trafiği değiştikçe, boşta olan bağlantılar etkin hale gelebilir ve etkin bağlantılar boşta kalabilir. Bağlantılar kötü kümelenmişse teklif veren sunucularınız üzerinde eşit olmayan yük oluşmasına neden olabilir. Google, sıcak bağlantıları zaman içinde otomatik olarak yeniden dengelemek için 10.000 istekten sonra tüm bağlantıları kapatarak bunu önlemeye çalışır. Trafiğin ortamınızda dengesiz hale geldiğini fark ederseniz aşağıdaki adımları izleyebilirsiniz:

  1. Ön uç proxy'leri kullanıyorsanız bağlantı başına bir defa yerine istek başına arka ucu seçin.
  2. Bir donanım yük dengeleyici veya güvenlik duvarı aracılığıyla bağlantılara proxy uyguluyorsanız ve bağlantılar kurulduktan sonra eşleme sabitlenirse bağlantı başına maksimum istek sayısı belirtin. Google'ın zaten bağlantı başına 10.000 isteklik bir üst sınır belirlediğini unutmayın. Bu nedenle, hâlâ etkin bağlantıların ortamınızda kümelendiğini görürseniz yalnızca daha katı bir değer sağlamanız gerekir. Örneğin Apache'de 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ı kapatacak şekilde yapılandırın.

Aşırı yüklenmeyle sorunsuz bir şekilde başa çıkın

İdeal olarak kotalar, teklif vereninizin yerine getirebileceği tüm istekleri alabilmesi için yeterince yüksek olacak ancak bu miktarın üstüne çıkamaz. Pratikte, kotaları optimum seviyelerde tutmak zor bir iştir ve aşırı yüklemelerin çeşitli nedenlerle meydana gelmesidir: yoğun dönemlerde arka ucun çalışmaması, her istek için daha fazla işlem yapılması gerekeceğinden bir trafik karışımının değişmesi veya kota değerinin çok yüksek olması. Sonuç olarak, çok fazla trafik geldiğinde teklif vereninizin nasıl davranacağını göz önünde bulundurmanız gerekir.

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

Teklif verenler, ağır yük altındaki davranışlar açısından üç geniş kategoriye ayrılır:

"Her şeye yanıt ver" teklif vereni

Bu teklif veren, uygulaması basit olsa da aşırı yüklendiğinde en kötü sonuçları verir. Bu nedenle, gelen her teklif isteğine yanıt vermeye çalışır ve ne olursa olsun hemen sunulamayacak teklifleri sıraya alır. Ortaya çıkan senaryo genellikle şöyle olur:

  • İstek oranı arttıkça tüm istekler zaman aşımına uğrayana kadar istek gecikmeleri de artar.
  • Çağrı oranları zirveye yaklaştıkça gecikmeler hızla artar
  • Kısıtlama devreye girerek izin verilen açıklama metinlerinin sayısını büyük ölçüde azalttı
  • Gecikmeler düzelmeye başlar ve bu da kısıtlamanın azalmasına neden olur
  • Döngü tekrar başlar.

Bu teklif verene ait gecikme grafiği, çok dik bir testere dişine benzer. Alternatif olarak, sıraya alınan istekler sunucunun bellek belleğini başlatmasına veya uzun süreli yavaşlamaya neden olan başka bir işlem yapmasına neden olur ve yoğun saatler sona erene kadar gecikmeler hiç düzelmez. Bu durum, yoğun kullanım döneminin tamamında çağrı oranlarının düşmesine neden olur. Her iki durumda da, kotanın daha düşük bir değere ayarlanmasına kıyasla daha az çağrı yapılır veya buna yanıt verilir.

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

Bu teklif veren, belirli bir orana kadarki açıklama metinlerini kabul eder, ardından bazı açıklama metinleri için hata döndürmeye başlar. Bu işlem dahili zaman aşımları, bağlantı sıralamayı devre dışı bırakma (Apache'de ListenBackLog tarafından kontrol edilir), kullanım veya gecikmeler çok yükseldiğinde olasılıksal düşüş modu uygulanması veya başka bir mekanizma aracılığıyla yapılabilir. Google %15'in üzerinde bir hata oranı saptarsa kısıtlamaya başlarız. "Her şeye yanıt ver" teklif vereninin aksine bu teklif veren, "kayıplarını azaltarak" istek oranları düştüğünde hemen iyileşmesine olanak tanır.

Bu teklif verene ait gecikme grafiği, aşırı yüklemeler sırasında kabul edilen maksimum oran civarında yerelleştirilmiş yüzeysel testere dişi kalıbına benzer.

"Aşırı yüklemede teklif vermeyen" teklif vereni

Bu teklif veren, belirli bir orana kadarki açıklama metinlerini kabul eder, ardından aşırı yükleme için "teklif yok" yanıtları döndürmeye başlar. "Aşırı yükleme hatası" teklif verenine benzer şekilde, bu da birkaç şekilde uygulanabilir. Burada farklı olan, Google'a hiçbir sinyalin geri döndürülmemesidir. Bu nedenle, açıklama metinlerini hiçbir zaman kısıtlamayız. Aşırı yük ön uç makineler tarafından emilir, böylece yalnızca arka uçlara doğru devam etmek için işleyebildikleri trafiğe izin verir.

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

"Aşırı yükleme hatası" ile "aşırı yüklemede teklif vermeme" yaklaşımını aşağıdaki şekilde birleştirmenizi öneririz:

  • Kullanıcı arabirimlerinin temel hazırlığını aşırı yapın ve bir biçimde yanıt verebilecekleri bağlantı sayısını en üst düzeye çıkarmaya yardımcı olmak için aşırı yükleme durumunda hata verecek şekilde ayarlayın.
  • Aşırı yüklemede hata oluşurken kullanıcı arabirimi makineleri hazır bir "teklif yok" yanıtı kullanabilir ve isteği ayrıştırması gerekmez.
  • Arka uçların durum denetimi uygulayın. Böylece arka uçlar, yeterli kapasiteye sahip değilse "teklif yok" yanıtı döndürür.

Bu, aşırı yükün bir kısmını ortadan kaldırır ve arka uçların tam olarak işleyebildikleri sayıda isteğe yanıt verme şansı tanır. Bunu, istek sayısı beklenenden önemli ölçüde yüksek olduğunda kullanıcı arabirimi makinelerinin "aşırı yükleme hatası" durumuna dönmesiyle "aşırı yüklemede teklif verilmemesi" olarak düşünebilirsiniz.

"Her şeye yanıt ver" teklif vereniniz varsa bağlantı davranışını ayarlayarak aşırı yüklenmeyi reddetmesi için bunu "aşırı yükleme hatası" teklif verenine 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 isteklere yanıt veremeyeceği bir duruma girmesini önler.

Ping'lere yanıt verme

Bağlantı yönetiminin kendi başına değil de teklif vereninizin ping isteklerine yanıt verebilmesini sağlamak hata ayıklama için şaşırtıcı derecede önemlidir. Google, teklif veren durumu, bağlantı kapatma davranışı, gecikme ve daha pek çok şeyin sağlık kontrolü ve hata ayıklama işlemleri için ping isteklerini kullanır. Ping istekleri aşağıdaki biçimde olur:

Google

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

OpenRTB JSON

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB Protokol Arabelleği

id: "7xd2P2M7K32d7F7Y50p631"

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

Eşleşmeyi deneyin

Ağ gecikmesini veya değişkenliğini azaltmanın diğer bir yolu da Google ile eşlemektir. Eşleme, teklif vereninize ulaşmak için izlediği yol trafiğinin optimize edilmesine yardımcı olur. Bağlantı uç noktaları aynı kalır ancak ara bağlantılar değişir. Ayrıntılı bilgi için Eşleme rehberini inceleyin. Eşlemenin en iyi uygulama olarak düşünülme nedeni şu şekilde özetlenebilir:

  • İnternet'te toplu taşıma bağlantıları öncelikli olarak "hot-patates yönlendirme" yöntemiyle seçilir. Bu bağlantı, ağımız dışında bir paketi hedefine gönderebilecek en yakın bağlantıyı bulup paketi bu bağlantı üzerinden yönlendirir. Trafik, birçok eşleme bağlantımızın olduğu bir sağlayıcıya ait omurganın bir bölümünden geçtiğinde seçilen bağlantı muhtemelen paketin başladığı yere yakın olur. Bu noktadan sonra paketin teklif verene kadar izlediği rota üzerinde kontrolümüz yoktur. Bu nedenle paket boyunca diğer otonom sistemlere (ağlara) geri dönebilir.

  • Buna karşılık, doğrudan eşleme sözleşmesi yapıldığında paketler her zaman bir eşleme bağlantısı boyunca gönderilir. Paket, nereden geldiğine bakılmaksızın Google'ın sahip olduğu veya kiraladığı bağlantıları, teklif verenin konumuna yakın olması gereken paylaşılan eşleme noktasına ulaşıncaya kadar aktarır. Ters seyahat, Google ağına kısa bir atlamayla başlar ve yolun geri kalanında Google ağında kalır. Seyahatin büyük bir kısmını Google'ın yönettiği altyapıda tutmak, paketin düşük gecikmeli bir rota izlemesini sağlar ve olası değişkenliği önler.

Statik DNS gönderin

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

Dengelemeye veya kullanılabilirliği yönetmeye çalışırken teklif verenlerin DNS sunucularından yaygın olarak kullanılan iki uygulamayı aşağıda bulabilirsiniz:

  1. DNS sunucusu, bir sorguya yanıt olarak bir adresi veya adreslerin bir alt kümesini dağıtır ve daha sonra bu yanıtın döngüsünü bir şekilde uygular.
  2. DNS sunucusu her zaman aynı adres grubuyla yanıt verir ancak yanıttaki adreslerin sırasını değiştirir.

Yığının birden çok düzeyinde çok fazla önbelleğe alma işlemi yapıldığından ilk teknik yük dengelemede kötüdür ve Google, DNS çözümleme süresini teklif verenden ücretlendirdiği için önbelleğe almayı atlama denemeleri de büyük olasılıkla tercih edilen sonuçları sağlamaz.

Google, DNS yanıt listesinden rastgele bir IP adresi seçtiği için ikinci teknikte yük dengeleme uygulanmaz. Bu nedenle yanıtın sırası önemli değildir.

Teklif veren bir 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.