Zaman aşımları ve son tarihler

Bu belgede, Rota Optimizasyonu API istekleri için zaman aşımı ve son tarih ayarlarının nasıl yapılandırılacağı açıklanmaktadır. Bu değerlerin ayarlanmaması veya yanlış ayarlanması bağlantı ya da yanıt kalitesi sorunlarına neden olabilir.

Zaman aşımını istek gövdesinde, son tarihi ise istek üstbilgisinde tanımlarsınız. Rota Optimizasyonu API'si, bu parametrelerle tanımlanan zaman sınırı içinde isteği işler ve en kısa zaman değerine uyar.

Zaman aşımlarını ve son tarihleri yapılandırmak, işlem süresini aşağıdaki şekillerde yönetmenize olanak tanır:

  • İşleme süresini artırma:
    • Yüksek karmaşıklıktaki istekleri çözme
    • Daha kaliteli yanıtlar alma
  • İşleme süresini kısaltma:
    • Düşük karmaşıklıktaki istekleri varsayılan modelden daha hızlı çözme
    • İstekleri daha kısa sürede çözebilir ancak daha düşük kaliteli yanıtlar alabilirsiniz.

Not: Zaman aşımı ve son tarih parametreleri yalnızca solvingMode, varsayılan değeri olan DEFAULT_SOLVE olarak ayarlandığında geçerli olur. solvingMode, VALIDATE_ONLY veya DETECT_SOME_INFEASIBLE_SHIPMENTS gibi diğer TRANSFORM_AND_RETURN_REQUEST seçenekleri genellikle çok daha hızlı oldukları için zaman aşımı ayarlamaları gerektirmez.

Zaman aşımı ve son tarih ihtiyaçlarınızı anlama

Zaman aşımlarınızı ve son tarihlerini yapılandırmadan önce bu bölümü inceleyerek uç nokta ve protokol seçimlerinizin bu ayarları nasıl etkilediğini anladığınızı doğrulayın.

Aşağıdaki yönergeler, hedeflerinize ulaşmak için doğru kurulumu kullanıp kullanmadığınızı doğrulamanıza yardımcı olabilir.

  • Sürekli ve tekrarlanan istekler ile daha uzun çözüm sürelerinden yararlanan karmaşık istekler için engellemeyen uç noktalar kullanın.
  • Kaliteden ödün vererek küçük istekler ve sonuçların hızlı iletilmesi için engelleme uç noktalarını kullanın.
  • Günlük iş akışınızda, özellikle üretim uygulamalarında gRPC'yi kullanın.
  • Test, deneme veya tek seferlik istekler için REST'i kullanın.

Bu belgenin hangi bölümlerinin kurulumunuzla en alakalı olduğunu belirlemenize yardımcı olabilecek bir şemayı görmek için aşağıdaki düğmeyi tıklayın.

Şemayı ayrı sekmede açma

timeout parametresini ayarlama

İstek gövdesindeki timeout parametresinin değerini, sunucunun yanıt döndürmeden önce bir istek üzerinde çalışacağı maksimum süreyi belirtecek şekilde ayarlayın. API, izin verilen maksimum süreye ulaşmadan önce optimum bir çözüm bulursa harcanan gerçek süre, ayrılan süreden daha kısa olabilir.

timeout parametresini, 1 saniye ile 1.800 saniye arasında değişebilen bir süre olan duration protokol arabelleğini kullanarak ayarlayın. allowLargeDeadlineDespiteInterruptionRisk kullanarak bu değeri 3.600 saniyeye kadar artırın.

Aşağıdaki tabloda, istek karmaşıklığına, gönderi ve araç sayısına göre önerilen timeout değerleri listelenmektedir.

Gönderim ve araç sayısı Kısıtlama yok Esnek zaman aralıkları ve yük kısıtlamaları veya uzun rotalar Kısa zaman aralıkları, yük kısıtlamaları, karmaşık kısıtlamalar veya çok uzun rotalar
1 - 8 2 sn 2 sn 5 sn.
9 - 32 5 sn. 10 saniye 20 saniye
33 - 100 15 sn. 30 sn. 60 sn.
101 - 1.000 45 sn. 90'lar 180'ler
1.001 - 10.000 120 sn. 360'lar 900'ler
10.001 veya daha fazla 10.000 gönderi başına 60 saniye + 120 saniye 10.000 gönderimde 360 10.000 gönderim başına 900 saniye

Son tarihi ayarlama

İstek üstbilgisinde son tarihi ayarlayarak Rota Optimizasyonu API'sinin bir isteği işlemek için harcayacağı maksimum süreyi tanımlayın. Aşağıdaki alt bölümlerde, REST ve gRPC istekleri için son tarihler belirleme açıklanmaktadır.

REST istekleri

Bir engelleme uç noktasını çağırmak için REST'i kullanırken son tarihi, genellikle karmaşık istekler için çok kısa olan 60 saniyelik varsayılan sürenin ötesine uzatabilirsiniz. İstek gövdesinde daha uzun bir son tarih belirtmiş olsanız bile bunu yapmanız gerekir. Bunun nedeni, varsayılan son tarihin, istek gövdesinde ayarlanan ve 60 saniyeden uzun olan tüm timeout değerlerini geçersiz kılmasıdır.

X-Server-Timeout istek üstbilgisini ayarlayarak son tarihi varsayılan 60 saniyenin ötesine uzatın. İstek gövdesinin aksine, başlığın değeri saniye sayısıdır ancak "s" soneki olmadan. Bu başlık için ayarlayabileceğiniz maksimum değer, timeout parametresinin kısıtlamalarıyla uyumludur.

Aşağıdaki kod örneğinde, X-Server-Timeout değeri 1.800 saniye olarak ayarlanmış bir HTTP üst bilgisi gösterilmektedir.

curl -X POST 'https://routeoptimization.googleapis.com/v1/projects/:optimizeTours' \
-H "Content-Type: application/json" \
-H "X-Server-Timeout: 1800" \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
--data @- << EOM
{
  "model": {
    ...
  }
}
EOM

İstemci kitaplıkları ve gRPC istekleri

İstemci kitaplıklarını veya gRPC'yi kullanırken son tarih yapılandırmanız gerekmez. Bu işlevler kullanılırken varsayılan son tarih 3.600 saniyedir. Bu, API için maksimum istek süresidir. Yalnızca istek gövdesinde zaman aşımı özelliğini ayarlayarak çözüm süresini yapılandırın.

Zaman aşımlarını ve son tarihleri etkileyen parametreler

Aşağıdaki parametreler hem zaman aşımlarının hem de son tarihlerinin işleyişini etkiler:

  • allowLargeDeadlineDespiteInterruptionRisk ile maksimum istek bitiş tarihini kontrol edin.
  • searchMode ile aramanın davranışını tanımlayın ve çözüm kalitesi ile gecikme arasında denge kurun.

allowLargeDeadlineDespiteInterruptionRisk

allowLargeDeadlineDespiteInterruptionRisk parametresi, maksimum istek son tarihini 3.600 saniyeye çıkarır. Bu parametre ayarlanmazsa hem zaman aşımı hem de son tarih parametreleri için maksimum değer 1.800 saniyedir.

Zaman aşımı ve son tarih parametrelerinin değerini 3.600 saniyeye kadar artırmak için allowLargeDeadline DespiteInterruptionRisk değerini true olarak ayarlayın.

allowLargeDeadline DespiteInterruptionRisk için izin verilen değerler şunlardır:

  • true: Kesinti riskini kabul ederken zaman aşımı ve son tarih parametrelerinin maksimum değerini 3.600 saniyeye çıkarır.
  • false (varsayılan): Zaman aşımı ve son tarih parametrelerinin maksimum değerini 1.800 saniye olarak tutar.

3.600 saniyeden daha uzun bir zaman aşımına ihtiyacınız olduğunu düşünüyorsanız Google temsilcinizle iletişime geçin.

searchMode

searchMode parametresi, optimize edicinin çözümleri nasıl aradığını kontrol ederek daha hızlı bir yanıt (daha düşük gecikme) veya daha yüksek kaliteli bir çözüme öncelik vermenize olanak tanır.

Daha yüksek çözüm kalitesini önceliklendirdiğinizde, optimizasyon aracı yüksek kaliteli bir çözüm bulmak için makul bir süreye ihtiyaç duyar. Bu uzun istekler için bağlantı sorunlarını önlemek amacıyla daha uzun bir zaman aşımı ayarlamayı ve engellemeyen uç noktaları kullanmayı düşünebilirsiniz.

searchMode için izin verilen değerler şunlardır:

  • SEARCH_MODE_UNSPECIFIED (varsayılan): Belirtilmemiş bir arama modu, RETURN_FAST ile eşdeğerdir.
  • RETURN_FAST: İlk iyi çözümü bulduktan sonra aramayı durdurur.
  • CONSUME_ALL_AVAILABLE_TIME: Daha iyi çözümler aramak için mevcut tüm zamanı harcar. API, erken bir aşamada optimum çözüm bulursa mevcut tüm süreyi kullanmaz.

Etkin tutma ping'lerini etkinleştirme

60 saniyeden uzun bir zaman aşımıyla engelleme uç noktalarına istekte bulunduğunuzda, yanıt beklerken bağlantı kaybını önlemek için canlı tutma ping'leri kullanılır. Etkin tutma ping'leri, bağlantı etkinliğini sürdürmek, bağlantı kaybını tespit etmek ve önlemek için gönderilen küçük paketlerdir.

Bu parametreleri, kullandığınız API protokolüne göre yapılandırın:

  • REST: TCP bağlantısı düzeyinde keepalive'ı yapılandırın.
  • gRPC: Temel TCP soketinde veya doğrudan gRPC protokolünde canlı tutma ping'lerini yapılandırın.

Aşağıdaki bölümlerde, her iki protokol için de canlı tutma ping'lerinin nasıl ayarlanacağı açıklanmaktadır.

REST keepalive

REST kullanırken etkin tutma ping'lerini yapılandırma, HTTP istemci kitaplığınıza bağlıdır. curl gibi istemci kitaplıkları ve araçlar, belirli yapılandırma seçenekleri sunabilir veya ping'leri otomatik olarak etkinleştirebilir.

Kitaplığınız temel TCP soketini kullanıma sunuyorsa SO_KEEPALIVE gibi seçenekleri kullanarak TCP soketinde doğrudan etkin tutma ping'lerini yapılandırabilirsiniz. Bunu setsockopt() gibi işlevleri veya bunların eşdeğerlerini kullanarak yapabilirsiniz.

GitHub'da barındırılan bu işlev, Python'ın yerleşik HTTP istemcisi için bu işlevin nasıl doğru şekilde ayarlanacağını gösterir.

TCP düzeyinde keepalive hakkında daha fazla bilgiyi TLDP keepalive genel bakış veya HTTP istemci kitaplığı belgelerinizde bulabilirsiniz.

gRPC keepalive

gRPC, protokolün bir parçası olarak kendi yerleşik keepalive mekanizmasını sunar. İstemci dilinizde bu ayarı nasıl yapacağınızla ilgili talimatlar için gRPC keepalive kılavuzuna bakın.

Not: gRPC sunucuları, çok fazla ping gönderen istemcileri reddedebilir. Etkin tutma ping sıklığını çok yüksek ayarlamaktan kaçının.

Etkin tutma ile gRPC örnek isteği

Aşağıdaki örnekte, Python istemci kitaplığı ve gRPC düzeyinde canlı tutma ping'leri kullanılarak nasıl optimizeTours isteği gönderileceği gösterilmektedir.

from google.maps import routeoptimization_v1 as ro
from google.maps.routeoptimization_v1.services.route_optimization.transports import grpc as grpc_transport
import sys

_REQUEST_TIMEOUT_SECONDS = 1800
_KEEPALIVE_PING_SECONDS = 30

def create_channel(*args, **kwargs):
  raw_options = kwargs.pop("options", ())
  options = dict(raw_options)
  options["grpc.keepalive_time_ms"] = _KEEPALIVE_PING_SECONDS * 1000
  options["grpc.keepalive_timeout_ms"] = 5000
  # Allow any number of pings between the request and the response.
  options["grpc.http2.max_pings_without_data"] = 0
  print(f"Using options: {options}", file=sys.stderr)
  return grpc_transport.RouteOptimizationGrpcTransport.create_channel(
      *args,
      options=list(options.items()),
      **kwargs,
  )

def create_grpc_transport(*args, **kwargs):
  if "channel" in kwargs:
    raise ValueError(
        "`channel` is overridden by this function, and must not be provided."
    )
  return grpc_transport.RouteOptimizationGrpcTransport(
      *args,
      channel=create_channel,
      **kwargs,
  )

def run_optimize_tours(request):
  client = ro.RouteOptimizationClient(transport=create_grpc_transport)
  return client.optimize_tours(request, timeout=_REQUEST_TIMEOUT_SECONDS)