GZT Uygulamaları için En İyi Uygulamalar

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

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 iki kaynağı yeniden kullanmak yerine iki taraf için de önemli bir değer taşıyor. Daha az kapatarak yoksa, açılması gereken bağlantıların sayısını azaltabilirsiniz. tekrar.

Ö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 derleyin. Oldukça fazla ortadan kaldırır.

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

Bağlantı davranışını ayarlayarak başlayın. Sunucu varsayılanlarının çoğu, ve her birinin az sayıda müşteriye sahip olduğu, çok sayıda kabul edersiniz. GZT için ise küçük bir makine havuzu, çok sayıda tarayıcı adına çalışmaktadır. 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.
• En yükseğe bir bağlantıdaki maksimum istek sayısı önemlidir.
• RAM'inizin yapabileceği en yüksek değere maksimum bağlantı sayısı mümkün olan en iyi uygulamaları kapsayarak bu değere çok yakın değildir.

Örneğin Apache’de bu, KeepAliveTimeout - 150, MaxKeepAliveRequests - 150 sıfır ve MaxClients'yi sunucu türüne bağlı bir değere dönüştürür.

Bağlantı davranışınız incelendikten sonra, teklif veren kodu bağlantıları gereksiz yere kapatmaz. Ö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ına uğraması için, kodun ilgili satırı kapatmadan bağlantı. Böylece teklif vereninizin teklif vermesi durumunda bağlantılar kapanmaya başlar ve zaman aşımlarının sayısı artarsa teklif vereninizin kısıtlanmasına neden olur.

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. Zaman içinde, Authorized Buyers programındaki ve satın alma sürecindeki bağlantı sayısı ve teklif verenin sunucularının yeniden başlatılması son derece değişken hale gelebilir.

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 bunu şu şekilde önlemeye çalışır: 10.000 istekten sonra tüm bağlantıları kapatmak, nasıl etkilediğini fark edebilirsiniz. Araç Çubuğu’nda trafiğin dengesiz hale geldiğini ya da atabileceğiniz başka adımlar da var:

1. Bağlantı başına bir kez değil, istek başına arka ucu seçin ön uç proxy'leri kullanıyorsanız.
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ümelenmesi anlamına gelir. Örneğin Apache’de MaxKeepAliveRequests değerini 5.000 olarak ayarla
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 tüm geri kalan her şeyi alması için yalnızca istek sayısını artırır. Pratikte kotaları optimum seviyeler zor bir görevdir ve aşırı yüklenmeler ile nedenler: arka uçların en yoğun dönemlerde çökmesi, trafik karmasının değişmesi ve Her istek için daha fazla işleme gerekir veya kota değeri henüz belirlenmemiştir çok yüksek. Sonuç olarak, teklif vereninizin diğer kullanıcılara çok fazla trafik alıyor olabilir.

Geçici trafik kaymalarını karşılamak için (bir haftaya kadar) bölgeler arasında (özellikle ABD'nin Asya ile ABD'sinin Batısı ile ABD'nin Doğu ve ABD Batısı arasında), İşlem başına 7 günlük zirve ile QPS arasında% 15'lik bir tampon olmasını öneririz. Konum.

Teklif verenler, ağır yük altındaki davranış açısından üç geniş kategoriler:

"Her şeye yanıt ver" teklif veren

Uygulaması basit olsa da bu teklif veren, en kötü teklifi verdiğinde aşırı yüklü. Gelen her teklif isteğine yanıt vermeye çalışır. hemen sunulması mümkün olmayan ürünleri sıraya koyuyoruz. Senaryo genellikle şöyle bir şey ortaya çıkar:

• İstek oranı arttıkça tüm isteklere kadar olan istek gecikmeleri de yükselir. zaman aşımına uğratmaya başla
• Çağrı oranları zirveye yaklaştıkça gecikmeler aniden artıyor
• Kısıtlama devreye girerek izin verilen açıklama metinlerinin sayısı büyük ölçüde azaldı
• 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 veya 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 yüksek yanıt verebilir.

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

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 ver" özelliğinden farklı olarak bu teklif verenin "kayıplarını azaltmayı” Böylece, istek ücretleri düştüğünde hemen iyileşebilir. aşağı tüketim.

Bu teklif verenin gecikme grafiği, sığ testere dişine benzemektedir aşırı yüklenme sırasında kalıp, kabul edilebilir maksimum değer civarında yerelleştirilmiş oranıdır.

"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ı" ile benzer teklif veren, bunun birkaç yolu vardır. Burada farklı olan şey, sinyali Google'a döndürülür, böylece hiçbir zaman açıklama metinlerini kısıtlamayız. İlgili içeriği oluşturmak için kullanılan Aşırı yük, kullanıcı arabirimi makineleri tarafından emilir ve bu da yalnızca trafiğin destekleyebilecekleri bir dizi kod içerir.

Bu teklif veren için gecikme grafiği, (yapay olarak) yoğun zamanlarda istek hızında paralellik sağlar ve bu süre içinde buna karşılık gelen 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çlarda, yeterli kapasiteye sahip olmadıklarında "no-bid" değeri döndürecek şekilde durum denetimi uygulayın. tıklayın.

Böylece aşırı yük bir miktar emilebilir ve arka uçlara mümkün olduğunca fazla isteğe yanıt verebilmelidir. Bunu, günlük hayatınızda "Aşırı yüklenmede teklif yok" gibi kullanıcı arabirimi makinelerinin "hata hatası" aşırı yüklenme" istek sayıları beklenenden önemli ölçüde yüksek olduğunda bu özelliği de kullanabilirsiniz.

"Her şeye yanıt ver" seçeneğine sahipseniz bu verileri "aşırı yükleme hatası" geçerli olacak şekilde ayarlama yaparak teklif vereni de ancak aşırı yüklenmeyi reddediyor. Bu, daha fazla hata döndürülmesine neden olsa da zaman aşımlarını azaltır ve sunucunun belirli bir süre içinde hiçbir isteğe yanıt veremez.

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 ping’i kullanır teklif veren durumunun doğruluk kontrolü ve hata ayıklaması istekleri, bağlantı kapatma öğrenebilirsiniz. Ping istekleri aşağıdaki biçimde olur:

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

"id": "4YB27BCXimH5g7wB39nd3t"

id: "7xd2P2M7K32d7F7Y50p631"

Bekleyebileceğinizin aksine, ping isteğinin herhangi bir reklam alanlarından oluşur. Ayrıca, yukarıda ayrıntılı olarak belirtildiği gibi, bir ping isteğine yanıt verdikten sonra bağlantıyı kapatmamalısınız.

Eşlemeyi düşünün

Ağ gecikmesini veya değişkenliği azaltmanın bir başka 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, toplu taşıma bağlantıları öncelikli olarak "hot-patates" üzerinden seçiliyor yönlendirme", Ağımızın dışında bulunan ve Google'dan kullanıcılarınıza hedefine gider 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 paketinin başlangıcını oluşturur. Bu noktadan sonra paketin rotası üzerinde kontrol sahibi değiliz. teklif vereni takip eder, bu nedenle diğer otonom sistemlere (ağlar) görürsünüz.

• 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 Google'ın sahip olduğu veya kiraladığı bağlantıları, paylaşılan eşleme noktasıdır. Bu bağlantı, teklif veren konumuna yakın olmalıdır. 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önder

Alıcıların Google'a her zaman tek bir statik DNS sonucu göndermesini ve trafik teslimini ele almak için Google'da çalışıyor.

Aşağıda, teklif verenlerin en sık kullandığı DNS sunucuları yüklenmeye çalışılırken bakiyeyi ayarlayın veya müsaitlik durumunu yönetin:

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ı

Birinci teknik, aynı hızda çok fazla önbelleğe alma olduğundan, yük dengelemede zayıftır ve önbelleğe almayı atlama teşebbüsleri büyük olasılıkla Google, DNS çözümleme süresini teklif vereni de içerir.

İ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.