Mengonfigurasi waktu tunggu dan batas waktu

Dokumen ini menjelaskan cara mengonfigurasi setelan waktu tunggu dan batas waktu untuk permintaan Route Optimization API. Jika nilai ini tidak ditetapkan atau ditetapkan secara tidak benar, masalah kualitas koneksi atau respons dapat terjadi.

Anda menentukan waktu tunggu dalam isi permintaan dan batas waktu dalam header permintaan. Route Optimization API memproses permintaan dalam batas waktu yang ditentukan oleh parameter ini, dengan mempertimbangkan nilai waktu tersingkat.

Mengonfigurasi waktu tunggu dan batas waktu memungkinkan Anda mengelola waktu pemrosesan dengan cara berikut:

  • Meningkatkan waktu pemrosesan:
    • Menyelesaikan permintaan dengan kompleksitas tinggi.
    • Mendapatkan respons yang lebih berkualitas.
  • Mengurangi waktu pemrosesan:
    • Menyelesaikan permintaan dengan kompleksitas rendah lebih cepat daripada default.
    • Menyelesaikan permintaan dalam waktu lebih singkat, tetapi mendapatkan respons berkualitas lebih rendah.

Memahami kebutuhan waktu tunggu dan batas waktu Anda

Tinjau bagian ini sebelum mengonfigurasi waktu tunggu dan batas waktu untuk memastikan Anda memahami pengaruh pilihan endpoint dan protokol terhadap setelan ini.

Panduan berikut dapat membantu Anda mengonfirmasi apakah Anda menggunakan penyiapan yang tepat untuk tujuan Anda.

  • Gunakan endpoint non-pemblokiran untuk permintaan berkelanjutan dan berulang serta untuk permintaan kompleks yang memerlukan waktu penyelesaian lebih lama.
  • Gunakan endpoint pemblokiran untuk permintaan kecil dan pengiriman hasil yang cepat, dengan menerima konsekuensi kualitas.
  • Gunakan gRPC: untuk alur kerja harian Anda, terutama untuk aplikasi produksi.
  • Gunakan REST untuk pengujian, eksperimen, atau permintaan satu kali.

Klik tombol di bawah untuk melihat diagram yang dapat membantu Anda menentukan bagian mana dari dokumen ini yang paling relevan dengan penyiapan Anda.

Buka diagram di tab terpisah

Menetapkan parameter timeout

Tetapkan nilai untuk parameter timeout dalam isi permintaan untuk menentukan waktu maksimum server mengerjakan permintaan sebelum menampilkan respons. Waktu aktual yang dihabiskan mungkin lebih singkat daripada waktu yang dialokasikan jika API menemukan solusi optimal sebelum mencapai waktu maksimum yang dialokasikan.

Tetapkan parameter timeout menggunakan buffer protokol durasi, yang merupakan durasi dalam detik yang dapat berkisar dari 1 detik hingga 1.800 detik. Tingkatkan nilai ini hingga 3.600 detik menggunakan allowLargeDeadlineDespiteInterruptionRisk.

Tabel berikut mencantumkan nilai timeout yang direkomendasikan berdasarkan kompleksitas permintaan serta jumlah pengiriman dan kendaraan.

Jumlah pengiriman dan kendaraan Tidak ada batasan Jendela waktu dan batasan muatan yang longgar atau rute yang panjang Jendela waktu yang ketat, batasan muatan, batasan yang kompleks, atau rute yang sangat panjang
1 - 8 2 dtk 2 dtk 5 dtk
9 - 32 5 dtk 10 dtk 20 dtk
33 - 100 15 dtk 30 dtk 60 dtk
101 - 1.000 45 dtk 90-an 180 dtk
1.001 - 10.000 120 dtk 360s 900s
10.001 atau lebih 60 dtk + 120 dtk per 10 ribu pengiriman 360 per 10 ribu pengiriman 900 dtk per 10 ribu pengiriman

Menetapkan batas waktu

Tetapkan batas waktu di header permintaan untuk menentukan waktu maksimum yang dihabiskan Route Optimization API untuk memproses permintaan. Subbagian berikut menjelaskan cara menetapkan batas waktu untuk permintaan REST dan gRPC.

Permintaan REST

Saat menggunakan REST untuk memanggil endpoint pemblokiran, Anda dapat memperpanjang batas waktu melebihi default 60 detik, yang sering kali terlalu singkat untuk permintaan yang kompleks. Anda harus melakukannya meskipun Anda telah menentukan batas waktu yang lebih lama dalam isi permintaan, karena batas waktu default menggantikan nilai timeout yang ditetapkan dalam isi permintaan yang lebih besar dari 60 detik.

Perpanjang batas waktu melebihi default 60 detik dengan menetapkan header permintaan X-Server-Timeout. Tidak seperti dalam isi permintaan, nilai header adalah jumlah detik, tetapi tanpa akhiran "s". Nilai maksimum yang dapat Anda tetapkan untuk header ini sesuai dengan batasan parameter timeout.

Contoh kode berikut menunjukkan header HTTP dengan X-Server-Timeout yang ditetapkan ke 1.800 detik.

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

Library klien dan permintaan gRPC

Anda tidak perlu mengonfigurasi batas waktu saat menggunakan library klien atau gRPC. Batas waktu default saat menggunakannya adalah 3.600 detik, yaitu waktu permintaan maksimum untuk API ini. Konfigurasikan waktu penyelesaian dengan hanya menetapkan properti waktu tunggu dalam isi permintaan.

Parameter yang memengaruhi waktu tunggu dan batas waktu

Parameter berikut memengaruhi cara kerja waktu tunggu dan batas waktu:

  • Kontrol batas waktu permintaan maksimum dengan allowLargeDeadlineDespiteInterruptionRisk.
  • Tentukan perilaku penelusuran, dengan menyeimbangkan kualitas solusi terhadap latensi dengan searchMode.

allowLargeDeadlineDespiteInterruptionRisk

Parameter allowLargeDeadlineDespiteInterruptionRisk meningkatkan batas waktu permintaan maksimum menjadi 3.600 detik. Jika parameter ini tidak ditetapkan, nilai maksimum untuk parameter waktu tunggu dan batas waktu adalah 1.800 detik.

Tetapkan allowLargeDeadline DespiteInterruptionRisk ke true untuk meningkatkan nilai parameter waktu tunggu dan batas waktu hingga 3.600 detik.

Nilai yang diizinkan untuk allowLargeDeadline DespiteInterruptionRisk adalah sebagai berikut:

  • true: Meningkatkan nilai maksimum untuk parameter waktu tunggu dan batas waktu menjadi 3.600 detik sekaligus mengakui risiko gangguan.
  • false (default): Mempertahankan nilai maksimum untuk parameter waktu tunggu dan batas waktu sebesar 1.800 detik.

Jika Anda merasa memerlukan waktu tunggu lebih dari 3.600 detik, hubungi perwakilan Google Anda.

searchMode

Parameter searchMode mengontrol cara pengoptimal menelusuri solusi, sehingga Anda dapat memprioritaskan respons yang lebih cepat (latensi lebih rendah) atau solusi berkualitas lebih tinggi.

Jika Anda memprioritaskan kualitas solusi yang lebih tinggi, pengoptimal akan memerlukan waktu yang cukup lama untuk menemukan solusi berkualitas tinggi. Untuk permintaan yang lebih lama ini, pertimbangkan untuk menetapkan waktu tunggu yang lebih lama dan menggunakan endpoint non-pemblokiran untuk menghindari masalah koneksi.

Nilai yang diizinkan untuk searchMode adalah sebagai berikut:

  • SEARCH_MODE_UNSPECIFIED (default): Mode penelusuran yang tidak ditentukan, setara dengan RETURN_FAST.
  • RETURN_FAST: Menghentikan penelusuran setelah menemukan solusi pertama yang baik.
  • CONSUME_ALL_AVAILABLE_TIME: Menghabiskan semua waktu yang tersedia untuk mencari solusi yang lebih baik. API tidak menggunakan semua waktu yang tersedia jika menemukan solusi optimal lebih awal.

Mengaktifkan ping keepalive

Saat Anda membuat permintaan ke endpoint pemblokiran dengan waktu tunggu lebih dari 60 detik, ping keepalive membantu mencegah hilangnya koneksi saat Anda menunggu respons. Ping keepalive adalah paket kecil yang dikirim untuk mempertahankan aktivitas koneksi, serta untuk mendeteksi dan mencegah hilangnya koneksi.

Konfigurasikan parameter ini berdasarkan protokol API yang Anda gunakan:

  • REST: Konfigurasikan keepalive di tingkat koneksi TCP.
  • gRPC: Konfigurasi ping keepalive pada soket TCP yang mendasarinya atau langsung di protokol gRPC.

Bagian berikut menjelaskan cara menyiapkan ping keepalive untuk kedua protokol.

Keepalive REST

Mengonfigurasi ping keepalive saat Anda menggunakan REST bergantung pada library klien HTTP Anda. Library klien dan alat, seperti curl, dapat menyediakan opsi konfigurasi tertentu atau mengaktifkan ping secara otomatis.

Jika library Anda mengekspos soket TCP yang mendasarinya, Anda dapat mengonfigurasi ping keepalive langsung di soket TCP menggunakan opsi seperti SO_KEEPALIVE. Lakukan ini dengan menggunakan fungsi seperti setsockopt() atau yang setara.

Fungsi yang dihosting di GitHub ini menunjukkan cara menyiapkan hal ini dengan benar untuk klien HTTP bawaan Python.

Temukan detail selengkapnya tentang keepalive tingkat TCP di ringkasan keepalive TLDP atau di dokumentasi library klien HTTP Anda.

Keepalive gRPC

gRPC menawarkan mekanisme keepalive bawaannya sendiri sebagai bagian dari protokol. Lihat panduan keepalive gRPC untuk mengetahui petunjuk cara menyiapkannya dalam bahasa klien Anda.

Contoh permintaan gRPC dengan keepalive

Contoh berikut menunjukkan cara membuat permintaan optimizeTours menggunakan library klien Python dan ping keepalive tingkat gRPC.

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)