Dokumen ini memberikan beberapa tips pemecahan masalah umum saat memublikasikan pesan ke topik Pub/Sub.
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 end-to-end, yaitu jumlah waktu yang diperlukan agar pesan yang dipublikasikan ke Pub/Sub dikirimkan ke klien pelanggan. Anda dapat mengamati latensi publikasi yang tinggi atau latensi menyeluruh, meskipun nilai jenis latensi lainnya rendah. Latensi publikasi yang tinggi dapat terjadi pada 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 latensi rendah dan throughput tinggi. Jika topik memiliki throughput yang rendah, resource yang terkait dengan topik tersebut dapat memerlukan waktu lebih lama untuk diinisialisasi.
Jika Anda menggunakan kebijakan penyimpanan pesan, kebijakan tersebut dapat memengaruhi latensi permintaan secara keseluruhan ke topik dan langganan. Periksa Implikasi performa dan ketersediaan saat menggunakan konfigurasi ini.
Jika klien penayang Anda melihat latensi publikasi yang jauh lebih tinggi daripada yang tercermin dalam metrik, hal itu mungkin merupakan tanda dari 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. Menyiapkan objek penayang baru dan menambahkan thread baru memiliki biaya latensi. Jika Anda menggunakan Cloud Functions untuk memublikasikan pesan, perlu diperhatikan 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 coba lagi.
Perlu diketahui 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 ditentukan. Hal ini dapat disebabkan oleh berbagai faktor, seperti permintaan yang tidak mencapai layanan Pub/Sub atau masalah performa yang memengaruhi permintaan.
Untuk memverifikasi bahwa permintaan publikasi mencapai 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 mencapai layanan Pub/Sub. Selain itu, untuk menyingkirkan kemungkinan terjadinya masalah yang berjeda, periksa tingkat error. Jika tingkat errornya sangat rendah, masalah ini mungkin muncul sesekali.
Jika permintaan menjangkau Pub/Sub, berikut beberapa kemungkinan penyebab operasi publikasi gagal dengan error DEADLINE_EXCEEDED:
Hambatan sisi klien
Kegagalan publikasi kemungkinan besar disebabkan oleh bottleneck sisi klien, seperti memori yang tidak cukup, 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 sedang diantrekan lebih cepat daripada dikirim ke layanan, yang secara bertahap meningkatkan latensi permintaan. Selain itu, periksa apakah salah satu dari hal berikut membantu menentukan kemungkinan bottleneck di sistem Anda:
Periksa apakah Anda memublikasikan pesan lebih cepat daripada yang dapat dikirim klien. 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 dalam callback objekFuture.Pastikan ada bandwidth upload yang cukup antara perangkat tempat penayang berjalan dan Google Cloud. Jaringan Wi-Fi pengembangan biasanya memiliki bandwidth 1-10 MB/dtk, atau 1.000-10.000 pesan biasa per detik. Memublikasikan pesan dalam satu loop tanpa ada pembatasan kapasitas dapat menghasilkan burst bandwidth tinggi yang singkat dalam jangka waktu yang singkat. Untuk menghindari hal ini, Anda dapat menjalankan penayang pada mesin dalam Google Cloud atau mengurangi kecepatan publikasi pesan agar sesuai dengan bandwidth yang tersedia.
Periksa apakah ada latensi yang sangat tinggi antara host Anda dan Google Cloud karena salah satu alasan seperti kemacetan jaringan startup atau firewall. Menghitung throughput jaringan memiliki petunjuk untuk mengetahui bandwidth dan latensi untuk berbagai skenario.
Pada akhirnya, ada batasan jumlah data yang dapat dipublikasikan oleh satu mesin. Anda mungkin perlu mencoba melakukan penskalaan secara horizontal atau menjalankan beberapa instance klien penayang di beberapa komputer. Menguji klien Cloud Pub/Sub untuk memaksimalkan performa streaming menunjukkan cara Pub/Sub melakukan penskalaan di satu VM Google Cloud dengan peningkatan jumlah CPU. Misalnya, Anda dapat mencapai 500 MB/dtk hingga 700 MB/dtk untuk pesan 1 KB pada instance Compute Engine 16 inti.
Durasi waktu tunggu publikasi tidak memadai
Guna 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 total waktu tunggu ke 600 detik. Meskipun Anda tidak mengakumulasi backlog besar pesan yang tidak terkirim, lonjakan sesekali dalam latensi permintaan dapat menyebabkan waktu tunggu publikasi habis. Namun, jika masalah Anda disebabkan oleh bottleneck yang terus-menerus, bukan karena waktu tunggu sesekali, mencoba ulang beberapa kali dapat menyebabkan lebih banyak error.
Masalah library klien
Anda mungkin menjalankan versi library klien dengan masalah umum. Daftar berikut mencakup pelacak masalah untuk semua library klien. Jika Anda menemukan masalah umum yang memengaruhi versi library klien yang digunakan, upgrade library klien ke versi terbaru. Tindakan ini memastikan bahwa Anda telah menerima 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, ada kemungkinan seseorang telah memperbarui topik untuk mengubah skema terkait, menghapus skema, atau menghapus revisi skema yang terkait dengan topik. Dalam kasus 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.