Dokumen ini memberikan beberapa tips pemecahan masalah umum saat memublikasikan pesan ke topik Pub/Sub standar.
Pelajari lebih lanjut cara Memublikasikan pesan ke topik dan berbagai fiturnya.
Latensi publikasi tinggi
Latensi publikasi adalah jumlah waktu yang diperlukan untuk menyelesaikan permintaan publikasi yang dikeluarkan oleh klien penayang. Latensi publikasi berbeda dengan latensi pengiriman menyeluruh, yaitu jumlah waktu yang diperlukan untuk mengirimkan pesan yang dipublikasikan ke Pub/Sub ke klien pelanggan. Anda mungkin mengamati latensi publikasi atau latensi menyeluruh yang tinggi, meskipun nilai jenis latensi lainnya rendah. Latensi publikasi yang tinggi dapat terjadi di klien penayang Pub/Sub, dalam pengiriman antara klien dan backend Pub/Sub, atau di backend Pub/Sub. Anda dapat memeriksa latensi publikasi yang terjadi di backend Pub/Sub menggunakan metrik topic/send_request_latencies. Latensi publikasi backend yang tinggi dapat terkait dengan faktor berikut:
Pub/Sub dirancang untuk pengiriman berlatensi rendah dan throughput tinggi. Jika topik memiliki throughput rendah, resource yang terkait dengan topik tersebut mungkin memerlukan waktu lebih lama untuk diinisialisasi.
Jika Anda menggunakan kebijakan penyimpanan pesan, kebijakan tersebut dapat memengaruhi latensi keseluruhan permintaan ke topik dan langganan. Periksa Implikasi performa dan ketersediaan penggunaan konfigurasi ini.
Jika klien penayang Anda mengamati latensi publikasi yang jauh lebih tinggi daripada yang tercermin dalam metrik, hal ini dapat menjadi tanda salah satu faktor sisi klien berikut:
Pastikan Anda tidak membuat penayang baru untuk setiap publikasi. Sebaiknya gunakan satu klien penayang per topik per aplikasi untuk memublikasikan semua pesan. Memulai objek penayang baru dan menambahkan thread baru memiliki biaya latensi. Jika Anda menggunakan fungsi Cloud Run untuk memublikasikan pesan, perhatikan bahwa pemanggilan juga dapat memengaruhi latensi publikasi.
Jika Anda mendapati bahwa setelan percobaan ulang default tidak memadai untuk kasus penggunaan Anda, lakukan penyesuaian yang sesuai. Namun, pastikan nilai baru tidak terlalu tinggi. Lihat cara mengonfigurasi Permintaan percobaan ulang.
Perhatikan bahwa latensi publikasi yang tinggi dapat menyebabkan error DEADLINE_EXCEEDED, yang akan dibahas di bagian berikutnya.
Operasi publikasi gagal dengan DEADLINE_EXCEEDED
Error DEADLINE_EXCEEDED selama permintaan publikasi menunjukkan bahwa permintaan gagal diselesaikan dalam waktu yang dialokasikan. Hal ini dapat disebabkan oleh berbagai faktor, seperti permintaan yang tidak menjangkau layanan Pub/Sub atau masalah performa yang memengaruhi permintaan.
Untuk memverifikasi bahwa permintaan publikasi menjangkau layanan Pub/Sub, pantau topik menggunakan metrik topic/send_request_count, yang dikelompokkan menurut response_code. Metrik ini membantu Anda menentukan apakah permintaan gagal sebelum mencapai topik Pub/Sub. Jika metrik kosong, ada faktor eksternal yang mencegah pesan menjangkau layanan Pub/Sub. Selain itu, untuk mengesampingkan kemungkinan masalah yang terputus-putus, periksa rasio error menggunakan grafik metrik topic/send_request_count yang disebutkan sebelumnya, atau halaman API & Layanan di konsol Google Cloud . Jika tingkat error sangat rendah, hal ini mungkin merupakan masalah yang bersifat sementara.
Jika permintaan menjangkau Pub/Sub, berikut beberapa kemungkinan penyebab operasi publikasi gagal dengan error DEADLINE_EXCEEDED:
Bottleneck sisi klien
Kegagalan publikasi kemungkinan disebabkan oleh bottleneck sisi klien, seperti memori yang tidak memadai, tekanan CPU, kondisi thread yang buruk, atau kemacetan jaringan di VM yang menghosting klien penayang. Jika panggilan Publish menampilkan DEADLINE_EXCEEDED, mungkin panggilan Publish asinkron dimasukkan ke antrean lebih cepat daripada dikirim ke layanan, yang secara bertahap meningkatkan latensi permintaan. Selain itu, periksa apakah salah satu hal berikut membantu menentukan kemungkinan bottleneck di sistem Anda:
Periksa apakah Anda memublikasikan pesan lebih cepat daripada klien dapat mengirimnya. Biasanya setiap panggilan
Publishasinkron menampilkan objekFuture. Untuk melacak jumlah pesan yang menunggu untuk dikirim, simpan jumlah pesan yang akan dikirim dengan setiap panggilanPublishdan hapus hanya di callback objekFuture.Pastikan Anda memiliki bandwidth upload yang memadai antara mesin tempat penayang berjalan dan Google Cloud. Jaringan Wi-Fi pengembangan biasanya memiliki bandwidth 1-10 MBps, atau 1.000-10.000 pesan standar per detik. Memublikasikan pesan dalam loop tanpa pembatasan kapasitas dapat menyebabkan lonjakan bandwidth tinggi dalam jangka waktu singkat. Untuk menghindari hal ini, Anda dapat menjalankan penayang di komputer dalam Google Cloud atau mengurangi kecepatan Anda memublikasikan pesan agar sesuai dengan bandwidth yang tersedia.
Periksa apakah Anda melihat latensi yang sangat tinggi antara host dan Google Cloud karena alasan apa pun seperti kemacetan jaringan atau firewall startup. Menghitung throughput jaringan memiliki petunjuk untuk mengetahui bandwidth dan latensi Anda untuk berbagai skenario.
Pada akhirnya, ada batasan jumlah data yang dapat dipublikasikan oleh satu mesin. Anda mungkin perlu mencoba menskalakan secara horizontal atau menjalankan beberapa instance klien penayang di beberapa komputer. Menguji klien Cloud Pub/Sub untuk memaksimalkan performa streaming menunjukkan cara Pub/Sub diskalakan di satu VM Google Cloud dengan peningkatan jumlah CPU. Misalnya, Anda dapat mencapai 500 MBps hingga 700 MBps untuk pesan 1 KB di instance Compute Engine 16 core.
Durasi waktu tunggu publikasi tidak memadai
Untuk mengurangi rasio waktu tunggu untuk panggilan publikasi, pastikan Anda memiliki waktu tunggu yang cukup lama yang ditentukan di setelan percobaan ulang klien penayang. Untuk setelan percobaan ulang, tetapkan batas waktu awal ke 10 detik dan waktu tunggu total ke 600 detik. Meskipun Anda tidak mengumpulkan banyak pesan yang belum terkirim, lonjakan latensi permintaan sesekali dapat menyebabkan waktu tunggu panggilan publikasi habis. Namun, jika masalah Anda disebabkan oleh bottleneck yang persisten, bukan waktu tunggu yang habis, mencoba lagi beberapa kali dapat menyebabkan lebih banyak error.
Masalah library klien
Anda mungkin menjalankan versi library klien dengan masalah umum. Daftar berikut menyertakan pelacak masalah untuk semua library klien. Jika Anda menemukan masalah umum yang memengaruhi versi library klien yang Anda gunakan, upgrade ke versi library klien terbaru. Tindakan ini memastikan bahwa Anda telah mengambil update yang relevan, termasuk perbaikan dan peningkatan performa.
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Masalah skema
Jika publikasi Anda mulai menampilkan INVALID_ARGUMENT, mungkin seseorang telah memperbarui topik untuk mengubah skema terkait, menghapus skema, atau menghapus revisi skema yang terkait dengan topik tersebut. Dalam hal ini, perbarui setelan skema topik ke skema dan kumpulan revisi yang cocok dengan pesan yang dipublikasikan, atau sesuaikan format pesan agar cocok dengan skema saat ini.
Masalah enkripsi pesan
Jika Anda telah mengonfigurasi topik Pub/Sub untuk mengenkripsi pesan yang dipublikasikan menggunakan kunci enkripsi yang dikelola pelanggan, publikasi dapat gagal dengan error FAILED_PRECONDITION. Error ini dapat terjadi jika kunci Cloud KMS dinonaktifkan atau jika kunci yang dikelola secara eksternal melalui Cloud EKM tidak dapat diakses lagi. Untuk melanjutkan publikasi, pulihkan akses ke kunci.