Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemrosesan dan pengaturan waktu pesan Amazon SQS
Topik ini memberikan panduan komprehensif tentang mengoptimalkan kecepatan dan efisiensi penanganan pesan di Amazon SQS, termasuk strategi untuk pemrosesan pesan tepat waktu, memilih mode polling terbaik, dan mengonfigurasi polling panjang untuk meningkatkan kinerja.
****Topik****
+ [Memproses pesan tepat waktu di Amazon SQS](best-practices-processing-messages-timely-manner.md)
+ [Mengatur polling panjang di Amazon SQS](best-practices-setting-up-long-polling.md)
+ [Menggunakan mode polling yang sesuai di Amazon SQS](best-practices-using-appropriate-polling-mode.md)
# Memproses pesan tepat waktu di Amazon SQS
Pengaturan batas waktu visibilitas tergantung pada berapa lama waktu yang dibutuhkan aplikasi Anda untuk memproses dan menghapus pesan. Misalnya, jika aplikasi Anda memerlukan 10 detik untuk memproses pesan dan Anda mengatur batas waktu visibilitas menjadi 15 menit, Anda harus menunggu waktu yang relatif lama untuk mencoba memproses pesan lagi jika upaya pemrosesan sebelumnya gagal. Atau, jika aplikasi Anda memerlukan 10 detik untuk memproses pesan tetapi Anda menetapkan batas waktu visibilitas hanya 2 detik, pesan duplikat diterima oleh konsumen lain saat konsumen asli masih mengerjakan pesan.
Untuk memastikan bahwa ada cukup waktu untuk memproses pesan, gunakan salah satu strategi berikut:
+ Jika Anda tahu (atau dapat memperkirakan secara wajar) berapa lama waktu yang dibutuhkan untuk memproses pesan, perpanjang *batas waktu visibilitas* pesan ke waktu maksimum yang diperlukan untuk memproses dan menghapus pesan. Untuk informasi selengkapnya, lihat [Mengonfigurasi Batas Waktu Visibilitas](sqs-visibility-timeout.md#configuring-visibility-timeout).
+ Jika Anda tidak tahu berapa lama waktu yang dibutuhkan untuk memproses pesan, buat *detak jantung* untuk proses konsumen Anda: Tentukan batas waktu visibilitas awal (misalnya, 2 menit) dan lalu—selama konsumen Anda masih mengerjakan pesan tersebut—terus perpanjang batas waktu visibilitas sebanyak 2 menit setiap menit.
**penting**
Batas waktu visibilitas maksimum adalah 12 jam dari waktu Amazon SQS menerima permintaan. `ReceiveMessage` Memperpanjang batas waktu visibilitas tidak mengatur ulang maksimum 12 jam.
Selain itu, Anda mungkin tidak dapat mengatur batas waktu pada pesan individual ke 12 jam penuh (misalnya 43.200 detik) sejak `ReceiveMessage` permintaan memulai pengatur waktu. Misalnya, jika Anda menerima pesan dan segera mengatur maksimum 12 jam dengan mengirim `ChangeMessageVisibility` panggilan `VisibilityTimeout` sama dengan 43.200 detik, kemungkinan akan gagal. Namun, menggunakan nilai 43.195 detik akan berfungsi kecuali ada penundaan yang signifikan antara meminta pesan melalui `ReceiveMessage` dan memperbarui batas waktu visibilitas. Jika konsumen Anda membutuhkan waktu lebih dari 12 jam, pertimbangkan untuk menggunakan Step Functions.
# Mengatur polling panjang di Amazon SQS
Ketika waktu tunggu untuk tindakan `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)` API lebih besar dari 0, *polling panjang* berlaku. Waktu tunggu polling maksimum yang panjang adalah 20 detik. Polling panjang membantu mengurangi biaya penggunaan Amazon SQS dengan mengurangi jumlah respons kosong (bila tidak ada pesan yang tersedia untuk `ReceiveMessage` permintaan) dan respons kosong palsu (saat pesan tersedia tetapi tidak disertakan dalam respons). Untuk informasi selengkapnya, lihat [Amazon SQS polling pendek dan panjang](sqs-short-and-long-polling.md).
Untuk pemrosesan pesan yang optimal, gunakan strategi berikut:
+ Dalam kebanyakan kasus, Anda dapat mengatur waktu `ReceiveMessage` tunggu menjadi 20 detik. Jika 20 detik terlalu lama untuk aplikasi Anda, tetapkan waktu `ReceiveMessage` tunggu yang lebih pendek (minimum 1 detik). Jika Anda tidak menggunakan AWS SDK untuk mengakses Amazon SQS, atau jika Anda mengonfigurasi SDK agar memiliki waktu tunggu AWS yang lebih singkat, Anda mungkin harus memodifikasi klien Amazon SQS untuk mengizinkan permintaan yang lebih lama atau menggunakan waktu tunggu yang lebih singkat untuk polling yang lama.
+ Jika Anda menerapkan polling panjang untuk beberapa antrian, gunakan satu utas untuk setiap antrian, bukan satu utas untuk semua antrian. Menggunakan satu utas untuk setiap antrian memungkinkan aplikasi Anda memproses pesan di setiap antrian saat tersedia, sementara menggunakan satu utas untuk polling beberapa antrian dapat menyebabkan aplikasi Anda tidak dapat memproses pesan yang tersedia di antrian lain saat aplikasi menunggu (hingga 20 detik) untuk antrian yang tidak memiliki pesan yang tersedia.
**penting**
Untuk menghindari kesalahan HTTP, pastikan batas waktu respons HTTP untuk `ReceiveMessage` permintaan lebih panjang dari `WaitTimeSeconds` parameter. Untuk informasi selengkapnya, lihat [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).
# Menggunakan mode polling yang sesuai di Amazon SQS
+ Polling panjang memungkinkan Anda mengkonsumsi pesan dari antrean Amazon SQS segera setelah tersedia.
+ Untuk mengurangi biaya penggunaan Amazon SQS dan mengurangi jumlah penerima kosong ke antrian kosong (tanggapan terhadap `ReceiveMessage` tindakan yang tidak menampilkan pesan), aktifkan polling panjang. Untuk informasi selengkapnya, lihat [Polling Panjang Amazon SQS](sqs-short-and-long-polling.md).
+ Untuk meningkatkan efisiensi saat melakukan polling untuk beberapa utas dengan beberapa penerima, kurangi jumlah utas.
+ Jajak pendapat panjang lebih disukai daripada polling pendek dalam banyak kasus.
+ Polling singkat segera mengembalikan respons, meskipun antrian Amazon SQS yang disurvei kosong.
+ Untuk memenuhi persyaratan aplikasi yang mengharapkan tanggapan segera terhadap `ReceiveMessage` permintaan, gunakan jajak pendapat singkat.
+ Jajak pendapat pendek ditagih sama dengan long polling.