Zaman aşımlarını ve son tarihleri yapılandırma

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 süre sınırı içinde isteği işler ve en kısa süre değerine uyar.

Zaman aşımlarını ve son tarihleri yapılandırarak işlem süresini aşağıdaki şekillerde yönetebilirsiniz:

  • İşleme süresini artırma:
    • Yüksek karmaşıklıktaki istekleri çözme
    • Daha kaliteli bir yanıt alma
  • İşleme süresini kısaltma:
    • Düşük karmaşıklıktaki istekleri varsayılandan daha hızlı çözün.
    • İsteği daha kısa sürede çözmek ancak daha düşük kaliteli bir yanıt almak.

Not: Zaman aşımı ve son tarih parametreleri yalnızca solvingMode, DEFAULT_SOLVE varsayılan değerine ayarlandığında geçerlidir. VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS veya TRANSFORM_AND_RETURN_REQUEST gibi diğer solvingMode 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ızdan emin olun.

Aşağıdaki yönergeler, hedefleriniz 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.
  • Küçük istekler ve sonuçların hızlı bir şekilde sunulması için engelleme uç noktalarını kullanın. Bu durumda kaliteden ödün vermeyi kabul etmiş olursunuz.
  • Günlük iş akışınızda, özellikle de üretim uygulamaları için gRPC'yi kullanın.
  • Test, deneme veya tek seferlik istekler için REST'i kullanın.

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

Diyagramı ayrı sekmede aç

timeout parametresini ayarlama

Sunucunun bir yanıt döndürmeden önce istek üzerinde çalışacağı maksimum süreyi belirtmek için istek gövdesindeki timeout parametresinin değerini ayarlayın. API, maksimum ayrılan 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 saniye cinsinden bir süre olan süre 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 listelenmiştir.

Gönderi 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 sn.
1.001 - 10.000 120 sn. 360'lar 900'ler
10.001 veya daha fazla 10 bin gönderi başına 60 sn + 120 sn 10.000 gönderi başına 360s 10.000 gönderimde 900 saniye

Son tarihi belirleme

Route Optimization API'nin bir isteği işlemek için harcayacağı maksimum süreyi tanımlamak üzere istek başlığında son tarihi ayarlayın. Aşağıdaki alt bölümlerde, REST ve gRPC istekleri için son tarihlerin nasıl ayarlanacağı açıklanmaktadır.

REST istekleri

Engelleme uç noktasını çağırmak için REST kullanırken son tarihi varsayılan 60 saniyenin ötesine uzatabilirsiniz. Bu süre genellikle karmaşık istekler için çok kısadır. İstek gövdesinde daha uzun bir son tarih belirtmiş olsanız bile bunu yapmanız gerekir. Çünkü varsayılan son tarih, istek gövdesinde ayarlanan ve 60 saniyeden uzun olan tüm timeout değerlerini geçersiz kılar.

X-Server-Timeout istek başlığını 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ğerinin 1.800 saniye olarak ayarlandığı bir HTTP üstbilgisi 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 API'ler kullanılırken varsayılan son tarih, bu API için maksimum istek süresi olan 3.600 saniyedir. İstek gövdesinde yalnızca 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 tarihlerin işleyişini etkiler:

  • allowLargeDeadlineDespiteInterruptionRisk ile maksimum istek son tarihini kontrol edin.
  • searchMode ile çözüm kalitesini gecikmeye karşı dengeleyerek aramanın davranışını tanımlayın.

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 ederek zaman aşımı ve son tarih parametrelerinin maksimum değerini 3.600 saniyeye çıkarır.
  • false (varsayılan): Zaman aşımı ve son tarih parametreleri için maksimum 1.800 saniye değerini korur.

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

searchMode

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

Daha yüksek çözüm kalitesine öncelik verdiğinizde optimize edici, yüksek kaliteli bir çözüm bulmak için makul bir süre harcar. Bu daha uzun istekler için daha uzun bir zaman aşımı süresi ayarlamayı ve bağlantı sorunlarını önlemek için engelleyici olmayan uç noktalar kullanmayı düşünebilirsiniz.

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

  • SEARCH_MODE_UNSPECIFIED (varsayılan): RETURN_FAST ile eşdeğer, belirtilmemiş bir arama modu.
  • RETURN_FAST: İlk iyi çözümü bulduktan sonra aramayı durdurur.
  • CONSUME_ALL_AVAILABLE_TIME: Daha iyi çözümler bulmak için tüm zamanını harcar. API, optimum bir çözümü erken bulursa mevcut sürenin tamamını kullanmaz.

Keepalive pinglerini etkinleştirme

Zaman aşımı süresi 60 saniyeden uzun olan engelleme uç noktalarına istek gönderdiğinizde, bağlantıda kalma ping'leri yanıt beklerken bağlantı kaybını önlemeye yardımcı olur. Keepalive ping'leri, bağlantı etkinliğini sürdürmek ve bağlantı kaybını tespit edip ö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 özelliğini yapılandırın.
  • gRPC: Temel TCP soketinde veya doğrudan gRPC protokolünde bağlantıyı etkin tutma ping'lerini yapılandırın.

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

REST keepalive

REST kullanırken keepalive ping'lerini yapılandırmak, 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 gösteriyorsa SO_KEEPALIVE gibi seçenekleri kullanarak etkin kalma ping'lerini doğrudan TCP soketinde yapılandırabilirsiniz. Bunu yapmak için setsockopt() gibi işlevleri veya bunların eşdeğerlerini kullanın.

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

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

gRPC keepalive

gRPC, protokolün bir parçası olarak kendi yerleşik etkin tutma mekanizmasını sunar. Bunu istemci dilinizde nasıl ayarlayacağınızla ilgili talimatlar için gRPC keepalive kılavuzunu inceleyin.

Not: gRPC sunucuları, çok fazla ping gönderen istemcileri reddedebilir. Etkin kalma 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 bağlantıda kalma 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)