Dokumen ini menjelaskan cara mengonfigurasi setelan waktu tunggu dan batas waktu untuk permintaan Route Optimization API. Tidak menyetel nilai ini atau menyetelnya dengan tidak benar dapat menyebabkan masalah kualitas koneksi atau respons.
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 terpendek.
Mengonfigurasi waktu tunggu dan batas waktu memungkinkan Anda mengelola waktu pemrosesan dengan cara berikut:
- Meningkatkan waktu pemrosesan:
- Menyelesaikan permintaan dengan kompleksitas tinggi.
- Mendapatkan respons berkualitas lebih tinggi.
- Mengurangi waktu pemrosesan:
- Menyelesaikan permintaan dengan kompleksitas rendah lebih cepat daripada default.
- Menyelesaikan permintaan dalam waktu lebih singkat, tetapi mendapatkan respons berkualitas lebih rendah.
Catatan: Parameter waktu tunggu dan batas waktu hanya berlaku jika solvingMode ditetapkan ke nilai defaultnya, yaitu DEFAULT_SOLVE. Opsi solvingMode lainnya, seperti VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS, atau TRANSFORM_AND_RETURN_REQUEST biasanya tidak memerlukan penyesuaian waktu tunggu karena jauh lebih cepat.
Memahami kebutuhan batas waktu dan tenggat Anda
Tinjau bagian ini sebelum mengonfigurasi waktu tunggu dan batas waktu untuk memverifikasi bahwa 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 sehari-hari, 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 dokumen ini yang paling relevan dengan penyiapan Anda.
Menetapkan parameter timeout
Tetapkan nilai untuk parameter timeout di isi permintaan untuk menentukan
waktu maksimum server memproses 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.
Nilai timeout yang direkomendasikan
Tabel berikut mencantumkan nilai timeout yang direkomendasikan berdasarkan kompleksitas permintaan dan jumlah pengiriman dan kendaraan.
| Jumlah pengiriman dan kendaraan | Tidak ada batasan | Jendela waktu yang tidak ketat dan batasan muatan 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-an |
| 1.001 - 10.000 | 120 dtk | 360-an | 900-an |
| 10.001 atau lebih | 60 detik + 120 detik 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 digunakan 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 telah menentukan batas waktu yang lebih lama dalam isi permintaan, karena batas waktu default akan mengganti 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 di isi permintaan, nilai header adalah jumlah detik, tetapi tanpa sufiks "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 3600 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, yang menyeimbangkan kualitas solusi dengan
latensi menggunakan
searchMode.
allowLargeDeadlineDespiteInterruptionRisk
Parameter allowLargeDeadlineDespiteInterruptionRisk meningkatkan
batas waktu permintaan maksimum menjadi 3600 detik. Jika parameter ini tidak ditetapkan, nilai maksimum untuk parameter waktu tunggu dan batas waktu adalah 1.800 detik.
Setel 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 sambil mengonfirmasi risiko gangguan.false(default): Mempertahankan nilai maksimum untuk parameter waktu tunggu dan batas waktu 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-blocking untuk menghindari masalah koneksi.
Nilai yang diizinkan untuk searchMode adalah sebagai berikut:
SEARCH_MODE_UNSPECIFIED(default): Mode penelusuran yang tidak ditentukan, setara denganRETURN_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 mendeteksi dan mencegah hilangnya koneksi.
Konfigurasikan parameter ini berdasarkan protokol API yang Anda gunakan:
- REST: Mengonfigurasi keepalive di tingkat koneksi TCP.
- gRPC: Mengonfigurasi ping keepalive pada soket TCP yang mendasarinya atau langsung dalam protokol gRPC.
Bagian berikut menjelaskan cara menyiapkan ping keepalive untuk kedua protokol.
Keep-alive REST
Mengonfigurasi ping keep-alive saat Anda menggunakan REST bergantung pada library klien HTTP Anda. Library klien dan alat, seperti curl, mungkin 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 fungsi ini dengan benar untuk klien HTTP bawaan Python.
Temukan detail selengkapnya tentang keepalive tingkat TCP di ringkasan keepalive TLDP atau dalam 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.
Catatan: Server gRPC mungkin menolak klien yang mengirim terlalu banyak ping. Hindari menyetel frekuensi ping keep-alive terlalu tinggi.
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)