Runtime Agen menyediakan parameter deployment yang memungkinkan Anda mengoptimalkan dan menskalakan performa agen. Dengan mengonfigurasi parameter ini, Anda dapat menangani pola traffic yang tidak terduga atau melonjak secara efektif.
Halaman ini menjelaskan praktik terbaik tentang cara mengoptimalkan dan menskalakan performa untuk Runtime Agen, yang mencakup skenario berikut:
Skenario ini menunjukkan cara menggunakan parameter deployment untuk mengatasi hambatan performa umum, terutama untuk pola traffic yang tidak terduga dan melonjak dalam aplikasi dunia nyata.
Masalah cold start
Cold start terjadi saat permintaan tiba dan tidak ada instance atau container yang tidak aktif untuk melayaninya, sehingga Runtime Agen harus memulai yang baru. Hal ini akan menambahkan latensi yang signifikan pada permintaan.
Misalnya, mengirim 300 permintaan serentak ke agen dengan min_instances=1 default dapat menunjukkan hasil berikut:
Cold start (run pertama): Latensi rata-rata sekitar 4,7 detik.
Warm start (run kedua langsung): Latensi rata-rata sekitar 0,4 detik.
Overhead lebih dari empat detik hampir seluruhnya disebabkan oleh instance baru yang dimulai untuk menangani beban.
Coba metode berikut untuk mengurangi masalah cold start:
Tetapkan nilai
min_instancesyang cukup tinggi untuk menangani traffic dasar pengukuran Anda. Misalnya, menetapkanmin_instances=10ke agen contoh dapat mengurangi latensi rata-rata untuk cold start menjadi sekitar 1,4 detik. Untuk aplikasi dengan traffic yang melonjak atau tinggi, tetapkanmin_instanceske nilai yang dapat menangani beban umum Anda tanpa perlu menskalakan dari 1. Nilai maksimumnya adalah 10.Kirim beban yang stabil, berkelanjutan, dan dapat diprediksi ke Runtime Agen menggunakan antrean. Misalnya, menjalankan uji beban berkelanjutan sebanyak 1.500 kueri per menit (25 kueri per detik) selama 60 detik pada agen berbasis Agent Development Kit (ADK) dengan
min_instances=10danconcurrencydefault (9) dapat menghasilkan hasil berikut:- Latensi rata-rata secara konsisten rendah, yaitu sekitar 1,6 detik.
Beban yang stabil dan berkelanjutan membuat layanan tetap warm dan menghasilkan performa yang optimal.
Pekerja asinkron yang kurang dimanfaatkan
Secara default, container_concurrency dikonfigurasi untuk kode sinkron, dengan setiap instance Platform Agen hanya menangani satu permintaan dalam satu waktu.
Agen asinkron, seperti yang berbasis
Agent Development Kit (ADK), dapat menangani beberapa
permintaan terikat I/O (seperti LLM atau panggilan alat) secara bersamaan.
Misalnya, mengirim 300 permintaan serentak ke agen berbasis ADK dengan min_instances=10 dan container_concurrency=9 default dapat menghasilkan hasil berikut:
- Meskipun latensi median sekitar 4 detik, latensi maksimum melonjak hingga 60 detik. Hal ini menunjukkan bahwa permintaan sangat banyak diantrekan saat layanan menskalakan secara perlahan.
Untuk mengurangi pekerja asinkron yang kurang dimanfaatkan, tingkatkan container_concurrency agar setiap instance Platform Agen dapat menangani beberapa permintaan. Jumlah permintaan serentak yang dapat ditangani oleh setiap proses agen adalah container_concurrency / 9. Nilai 9 mewakili jumlah proses agen yang berjalan secara paralel dalam setiap container.
Misalnya, mengirim 300 permintaan serentak ke agen berbasis ADK yang sama dengan min_instances=10 dan container_concurrency=36 dapat menghasilkan hasil berikut:
- Latensi maksimum turun dari 60 detik menjadi sekitar 7 detik. Hal ini menunjukkan bahwa instance yang ada dapat menyerap lonjakan traffic dengan lebih efektif.
Untuk agen asinkron (seperti agen berbasis ADK), tetapkan container_concurrency ke kelipatan 9 (misalnya, 36) sebagai titik awal. Hal ini meningkatkan responsivitas terhadap lonjakan traffic dan mengurangi latensi dari penskalaan.
Perhatikan bahwa menetapkan nilai container_concurrency terlalu tinggi dapat berisiko menyebabkan error kehabisan memori (OOM).
Langkah berikutnya
Mengelola agen yang di-deploy
Pelajari cara mengelola agen yang telah di-deploy ke runtime terkelola Platform Agen.