Sebuah kampanye dapat mengirim permintaan lebih cepat daripada jalur pengirimannya memproses pesan. Merencanakan pengiriman memerlukan estimasi kapasitas untuk setiap tahap.
Apa perbedaan pembatasan laju permintaan API dengan throughput?
Pembatasan laju permintaan API mengendalikan permintaan. Throughput pengiriman mengendalikan seberapa cepat tahap berikutnya dapat memproses pesan atau segmen.
Ketika Bird menolak permintaan dengan 429, ikuti header respons dan panduan pembatasan laju permintaan. Langsung mencoba lagi dapat mengulang penolakan yang sama.
Keberhasilan mengirim permintaan memiliki arti berbeda. 202 mengonfirmasi bahwa permintaan diterima, sedangkan penagihan, pengiriman ke jaringan, dan pengiriman ke penerima terjadi setelahnya. Gunakan identifier pesan untuk melacak hasil-hasil tersebut.
Twilio mengantrekan pesan ketika pengajuan melebihi laju pengiriman dan melaporkan kesalahan antrean penuh ketika kapasitasnya terlampaui: “Customers sending large volumes of messages may encounter errors such as Queue Overflow”.
Apa yang menentukan laju yang tersedia?
Laju efektif bergantung pada pengirim, tujuan, registrasi, konfigurasi penyedia, dan batas akun yang berlaku.
Short code dan long code dapat memiliki kapasitas berbeda di tujuan yang sama. Registrasi dapat memengaruhi lalu lintas yang boleh dibawa pengirim. Periksa pilihan pengirim dan persyaratan tujuan sebelum merencanakan volume.
Angka maksimum yang dipublikasikan adalah batas kapasitas, bukan jaminan pengiriman. Konfirmasi satuan, cakupan, dan kondisi sebelum menerapkannya pada kampanye.
Bagaimana cara memperkirakan waktu pengiriman?
Bagi jumlah pekerjaan dengan laju yang diukur dalam satuan yang sama. Segmen adalah teks yang dibawa dalam satu pesan jaringan. Teks yang lebih panjang menggunakan beberapa segmen.
Untuk contoh rute yang dibatasi 100 segmen per detik, 6.000 pesan satu segmen memerlukan setidaknya 60 detik kapasitas. Jika setiap pesan membutuhkan dua segmen, pekerjaan yang sama memerlukan setidaknya 120 detik.
Perhitungan tersebut mengasumsikan penggunaan kapasitas yang disebutkan secara terus-menerus. Lalu lintas lain, jeda, percobaan ulang, dan kondisi hilir dapat memperpanjang waktunya. Perhitungan ini tidak memprediksi kapan setiap penerima membaca atau menerima pesan.
Periksa isi pesan yang dipersonalisasi dengan kalkulator segmen. Nama yang lebih panjang atau emoji dapat mengubah jumlah teks yang ditagihkan.
Mengapa pesan tertunda padahal permintaan saya berhasil?
Antrean, pemrosesan hilir, kondisi jaringan, dan ketersediaan penerima semuanya dapat memisahkan penerimaan permintaan dari pengiriman pesan ke penerima.
Bandingkan waktu penerimaan permintaan, pengiriman ke jaringan, dan waktu pesan tersampaikan yang dilaporkan. Periksa error berdasarkan pengirim dan tujuan. Tanda terima yang tidak ada tidak dengan sendirinya mengidentifikasi penyebab.
Pusat pesan SMS dapat menyimpan pesan selama ponsel tidak tersedia. Apa itu SMSC menjelaskan tahap tersebut. Analitik SMS menjelaskan cara menyelidiki hasil di Bird.
Jangan kirim ulang pesan yang permintaan pengirimannya sudah diterima hanya karena tanda terima pengiriman terlambat. Hal itu dapat membuat teks duplikat tanpa menyelesaikan keterlambatan.
Bagaimana cara mempersiapkan kampanye yang lebih besar?
Pilih pengirim dan rencana kapasitas yang sesuai dengan lalu lintas, lalu uji pengiriman ke kelompok penerima terbatas sebelum memperluasnya.
Diskusikan negara tujuan, volume segmen, dan rentang waktu pengiriman yang dibutuhkan dengan penyedia. Registrasi dan persiapan pengirim mungkin diperlukan sebelum peluncuran volume lebih tinggi.
Menyebarkan lalu lintas ke nomor tambahan untuk menghindari batas operator dikenal sebagai snowshoeing. Prinsip CTIA membahas praktik tersebut.
- Hitung segmen yang dirender berdasarkan tujuan.
- Konfirmasi laju, satuan, dan cakupan untuk setiap jalur pengiriman.
- Sediakan waktu untuk pemrosesan dan variasi hilir.
- Kirim ke kelompok penerima terbatas, periksa hasilnya, dan perluas dengan pertimbangan yang matang.
Singkatnya
Kapasitas API dan kapasitas pengiriman mengukur tahap yang berbeda.
Permintaan yang berhasil tidak menjamin bahwa setiap pesan dapat langsung keluar ke jaringan.
Periksa satuan yang digunakan untuk menyatakan batas tersebut.
Permintaan, pesan, dan segmen menghasilkan perhitungan kapasitas yang berbeda.
Pengiriman tertunda memiliki beberapa kemungkinan penyebab.
Periksa antrean, error, dan kejadian pengiriman sebelum mengatribusikan keterlambatan pada throughput.
Rencanakan kapasitas untuk pengirim dan tujuan.
Batas akun, registrasi, dan aturan operator juga dapat membatasi jalur pengiriman.