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.
Dengan mengonfigurasi waktu tunggu dan batas waktu, Anda dapat mengelola waktu pemrosesan dengan cara berikut:
- Menambah 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 yang 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 diuntungkan dari waktu penyelesaian yang lebih lama.
- Gunakan endpoint pemblokiran untuk permintaan kecil dan pengiriman hasil yang cepat, dengan mengorbankan kualitas.
- Gunakan gRPC: untuk alur kerja sehari-hari 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 dokumen ini yang paling relevan dengan penyiapan Anda.
Membuka diagram di tab terpisah
Tetapkan parameter timeout
Tetapkan nilai untuk parameter timeout di isi permintaan untuk menentukan
waktu maksimum server memproses permintaan sebelum menampilkan respons. Waktu yang sebenarnya digunakan 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 sempit, batasan beban, batasan 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-an | 360-an | 900-an |
| 10.001 atau lebih | 60 detik + 120 detik per 10 ribu pengiriman | 360 per 10 ribu pengiriman | 900-an 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 di luar 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 akan menggantikan nilai timeout yang ditetapkan dalam
isi permintaan yang lebih besar dari 60 detik.
Perpanjang batas waktu di luar 60 detik default dengan menyetel 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 3.600 detik, waktu permintaan maksimum untuk API ini. Konfigurasi waktu penyelesaian dengan hanya menyetel properti waktu tunggu dalam isi permintaan.
Parameter yang memengaruhi waktu tunggu dan tenggat waktu
Parameter berikut memengaruhi fungsi batas waktu dan batas akhir:
- 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.
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 yakin memerlukan waktu tunggu lebih dari 3.600 detik, hubungi perwakilan Google Anda.
searchMode
Parameter searchMode mengontrol cara pengoptimalan menelusuri
solusi, sehingga Anda dapat memprioritaskan respons yang lebih cepat (latensi lebih rendah)
atau solusi yang 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 menyetel 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 baik pertama.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 keep-alive
Saat Anda membuat permintaan ke endpoint pemblokiran dengan waktu tunggu lebih dari 60 detik, ping keep-alive membantu mencegah hilangnya koneksi saat Anda menunggu respons. Ping keep-alive adalah paket kecil yang dikirim untuk mempertahankan aktivitas koneksi, serta mendeteksi dan mencegah hilangnya koneksi.
Konfigurasi parameter ini berdasarkan protokol API yang Anda gunakan:
- REST: Mengonfigurasi keepalive di tingkat koneksi TCP.
- gRPC: Mengonfigurasi ping keepalive pada soket TCP pokok atau langsung dalam protokol gRPC.
Bagian berikut menjelaskan cara menyiapkan ping keepalive untuk kedua protokol.
Tetap aktif REST
Mengonfigurasi ping keep-alive saat Anda menggunakan REST bergantung pada library klien HTTP Anda. Alat dan library klien, seperti curl, dapat memberikan opsi konfigurasi
tertentu atau mengaktifkan ping secara otomatis.
Jika library Anda mengekspos soket TCP yang mendasarinya, Anda dapat mengonfigurasi ping keep-alive 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 di dokumentasi library klien HTTP Anda.
Keepalive gRPC
gRPC menawarkan mekanisme tetap aktif bawaannya sendiri sebagai bagian dari protokol. Lihat panduan keep-alive gRPC untuk mendapatkan petunjuk tentang cara menyiapkannya dalam bahasa klien Anda.
Catatan: Server gRPC dapat menolak klien yang mengirim terlalu banyak ping. Hindari menyetel frekuensi ping keep-alive terlalu tinggi.
Contoh permintaan gRPC dengan keep-alive
Contoh berikut menunjukkan cara membuat permintaan optimizeTours menggunakan
library klien Python dan ping keep-alive 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)