Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik terbaik Amazon SQS
Amazon SQS mengelola dan memproses antrian pesan, memungkinkan berbagai bagian aplikasi untuk bertukar pesan secara andal dan dalam skala besar. Topik ini mencakup praktik terbaik operasional utama, termasuk menggunakan polling panjang untuk mengurangi respons kosong, menerapkan antrian huruf mati untuk menangani kesalahan pemrosesan, dan mengoptimalkan izin antrian untuk keamanan.
****Topik****
+ [Penanganan kesalahan dan pesan bermasalah](best-practices-error-handling.md)
+ [Deduplikasi dan pengelompokan pesan](best-practices-message-deduplication.md)
+ [Pemrosesan dan pengaturan waktu pesan](best-practices-message-processing.md)
# Penanganan kesalahan Amazon SQS dan pesan bermasalah
Topik ini memberikan petunjuk terperinci tentang mengelola dan mengurangi kesalahan di Amazon SQS, termasuk teknik untuk menangani kesalahan permintaan, menangkap pesan bermasalah, dan mengonfigurasi retensi antrian huruf mati untuk memastikan keandalan pesan.
****Topik****
+ [Menangani kesalahan permintaan di Amazon SQS](handling-request-errors.md)
+ [Menangkap pesan bermasalah di Amazon SQS](capturing-problematic-messages.md)
+ [Mengatur retensi antrian huruf mati di Amazon SQS](setting-up-dead-letter-queue-retention.md)
# Menangani kesalahan permintaan di Amazon SQS
Untuk menangani kesalahan permintaan, gunakan salah satu strategi berikut:
+ Jika Anda menggunakan AWS SDK, Anda sudah memiliki logika *coba ulang dan backoff* otomatis yang Anda inginkan. Untuk informasi selengkapnya, lihat [Error Retries dan Exponential Backoff](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) di. AWS*Referensi Umum Amazon Web Services*
+ Jika Anda tidak menggunakan fitur AWS SDK untuk coba lagi dan backoff, izinkan jeda (misalnya, 200 ms) sebelum mencoba kembali [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)tindakan setelah tidak menerima pesan, batas waktu, atau pesan kesalahan dari Amazon SQS. Untuk penggunaan selanjutnya `ReceiveMessage` yang memberikan hasil yang sama, biarkan jeda yang lebih lama (misalnya, 400 ms).
# Menangkap pesan bermasalah di Amazon SQS
Untuk menangkap semua pesan yang tidak dapat diproses, dan untuk mengumpulkan CloudWatch metrik yang akurat, konfigurasikan [antrian huruf mati](sqs-dead-letter-queues.md).
+ Kebijakan redrive mengalihkan pesan ke antrean huruf mati setelah antrian sumber gagal memproses pesan beberapa kali tertentu.
+ Menggunakan antrian surat mati mengurangi jumlah pesan dan mengurangi kemungkinan mengekspos Anda ke pesan *pil racun* (pesan yang diterima tetapi tidak dapat diproses).
+ Termasuk pesan pil racun dalam antrian dapat mendistorsi [`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md) CloudWatch metrik dengan memberikan usia yang salah dari pesan pil racun. Mengkonfigurasi antrian huruf mati membantu menghindari alarm palsu saat menggunakan metrik ini.
# Mengatur retensi antrian huruf mati di Amazon SQS
Untuk antrian standar, kedaluwarsa pesan selalu didasarkan pada stempel waktu enqueue aslinya. Ketika pesan dipindahkan ke antrian huruf mati, stempel waktu enqueue tidak berubah. `ApproximateAgeOfOldestMessage`Metrik menunjukkan kapan pesan dipindahkan ke antrian huruf mati, *bukan* saat pesan awalnya dikirim. Misalnya, asumsikan bahwa pesan menghabiskan 1 hari dalam antrian asli sebelum dipindahkan ke antrian huruf mati. Jika periode retensi antrian surat mati adalah 4 hari, pesan akan dihapus dari antrian surat mati setelah 3 hari dan 3 hari. `ApproximateAgeOfOldestMessage` Dengan demikian, ini adalah praktik terbaik untuk selalu mengatur periode retensi antrian huruf mati menjadi lebih lama dari periode retensi antrian asli.
Untuk antrian FIFO, stempel waktu enqueue akan disetel ulang saat pesan dipindahkan ke antrian huruf mati. `ApproximateAgeOfOldestMessage`Metrik menunjukkan kapan pesan dipindahkan ke antrian huruf mati. Dalam contoh yang sama di atas, pesan dihapus dari antrian huruf mati setelah 4 hari dan `ApproximateAgeOfOldestMessage` adalah 4 hari.
# Deduplikasi dan pengelompokan pesan Amazon SQS
Topik ini memberikan praktik terbaik untuk memastikan pemrosesan pesan yang konsisten di Amazon SQS. Ini menjelaskan cara menggunakan:
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax)untuk mencegah duplikat pesan dalam antrian FIFO.
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)untuk mengelola pemesanan pesan dalam grup pesan yang berbeda.
****Topik****
+ [Menghindari pemrosesan pesan yang tidak konsisten di Amazon SQS](avoiding-inconsistent-message-processing.md)
+ [Menggunakan ID deduplikasi pesan](using-messagededuplicationid-property.md)
+ [Menggunakan ID grup pesan](using-messagegroupid-property.md)
+ [Menggunakan ID percobaan permintaan terima](using-receiverequestattemptid-request-parameter.md)
# Menghindari pemrosesan pesan yang tidak konsisten di Amazon SQS
Karena Amazon SQS adalah sistem terdistribusi, adalah mungkin bagi konsumen untuk tidak menerima pesan bahkan ketika Amazon SQS menandai pesan sebagai terkirim saat berhasil kembali dari [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)panggilan metode API. Dalam hal ini, Amazon SQS mencatat pesan yang dikirimkan setidaknya sekali, meskipun konsumen belum pernah menerimanya. Karena tidak ada upaya tambahan untuk mengirimkan pesan dalam kondisi ini, kami tidak menyarankan menyetel jumlah penerimaan maksimum menjadi 1 untuk [antrian huruf mati](sqs-dead-letter-queues.md).
# Menggunakan ID deduplikasi pesan di Amazon SQS
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)adalah token yang hanya digunakan dalam antrian Amazon SQS FIFO untuk mencegah pengiriman pesan duplikat. Ini memastikan bahwa dalam jendela deduplikasi 5 menit, hanya satu contoh pesan dengan ID deduplikasi yang sama diproses dan dikirim.
Jika Amazon SQS telah menerima pesan dengan ID deduplikasi tertentu, pesan berikutnya dengan ID yang sama akan diakui tetapi tidak dikirimkan ke konsumen.
**catatan**
Amazon SQS terus melacak ID deduplikasi bahkan setelah pesan diterima dan dihapus.
**Topics**
+ [Kapan memberikan ID deduplikasi pesan di Amazon SQS](providing-message-deduplication-id.md)
+ [Mengaktifkan deduplikasi untuk sistem produsen/konsumen tunggal di Amazon SQS](single-producer-single-consumer.md)
+ [Skenario pemulihan pemadaman di Amazon SQS](designing-for-outage-recovery-scenarios.md)
+ [Mengonfigurasi batas waktu visibilitas di Amazon SQS](working-with-visibility-timeouts.md)
# Kapan memberikan ID deduplikasi pesan di Amazon SQS
Produser harus menentukan ID deduplikasi pesan dalam skenario berikut:
+ Saat mengirim badan pesan identik yang harus diperlakukan sebagai unik.
+ Saat mengirim pesan dengan konten yang sama tetapi atribut pesan yang berbeda, memastikan setiap pesan diproses secara terpisah.
+ Saat mengirim pesan dengan konten yang berbeda (misalnya, penghitung coba lagi di badan pesan) tetapi mengharuskan Amazon SQS untuk mengenalinya sebagai duplikat.
# Mengaktifkan deduplikasi untuk sistem produsen/konsumen tunggal di Amazon SQS
Jika Anda memiliki satu produsen dan satu konsumen, dan pesannya unik karena menyertakan ID pesan khusus aplikasi di badan, ikuti praktik terbaik berikut:
+ Aktifkan deduplikasi berbasis konten untuk antrian (setiap pesan Anda memiliki badan yang unik). Produser dapat menghilangkan ID deduplikasi pesan.
+ Saat deduplikasi berbasis konten diaktifkan untuk antrean Amazon SQS FIFO, dan pesan dikirim dengan ID deduplikasi, ID deduplikasi akan mengganti ID deduplikasi berbasis konten yang dihasilkan. [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)
+ Meskipun konsumen tidak diharuskan untuk memberikan ID percobaan permintaan terima untuk setiap permintaan, ini adalah praktik terbaik karena memungkinkan urutan coba gagal untuk dijalankan lebih cepat.
+ Anda dapat mencoba lagi mengirim atau menerima permintaan karena tidak mengganggu urutan pesan dalam antrian FIFO.
# Skenario pemulihan pemadaman di Amazon SQS
Proses deduplikasi dalam antrian FIFO sensitif terhadap waktu. Saat merancang aplikasi Anda, pastikan bahwa produsen dan konsumen dapat pulih dari pemadaman klien atau jaringan tanpa menimbulkan duplikat atau kegagalan pemrosesan.
Pertimbangan produsen
+ Amazon SQS memberlakukan jendela deduplikasi 5 menit.
+ Jika produser mencoba ulang [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)permintaan setelah 5 menit, Amazon SQS memperlakukannya sebagai pesan baru, berpotensi membuat duplikat.
Pertimbangan konsumen
+ Jika konsumen gagal memproses pesan sebelum batas waktu visibilitas berakhir, konsumen lain dapat menerima dan memprosesnya, yang mengarah ke pemrosesan duplikat.
+ Sesuaikan batas waktu visibilitas berdasarkan waktu pemrosesan aplikasi Anda.
+ Gunakan [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html)API untuk memperpanjang batas waktu saat pesan masih diproses.
+ Jika pesan berulang kali gagal diproses, arahkan ke [antrian huruf mati (DLQ)](sqs-dead-letter-queues.md) alih-alih membiarkannya diproses ulang tanpa batas waktu.
+ Produsen harus menyadari interval deduplikasi antrian. Amazon SQS memiliki interval deduplikasi 5 menit. Mencoba kembali `SendMessage` permintaan setelah interval deduplikasi berakhir dapat memperkenalkan pesan duplikat ke dalam antrian. Misalnya, perangkat seluler di dalam mobil mengirim pesan yang pesanannya penting. Jika mobil kehilangan konektivitas seluler untuk jangka waktu tertentu sebelum menerima pengakuan, mencoba kembali permintaan setelah mendapatkan kembali konektivitas seluler dapat membuat duplikat.
+ Konsumen harus memiliki batas waktu visibilitas yang meminimalkan risiko tidak dapat memproses pesan sebelum batas waktu visibilitas berakhir. Anda dapat memperpanjang batas waktu visibilitas saat pesan sedang diproses dengan memanggil tindakan. `ChangeMessageVisibility` Namun, jika batas waktu visibilitas berakhir, konsumen lain dapat segera mulai memproses pesan, menyebabkan pesan diproses beberapa kali. Untuk menghindari skenario ini, konfigurasikan [antrian huruf mati](sqs-dead-letter-queues.md).
# Mengonfigurasi batas waktu visibilitas di Amazon SQS
Untuk memastikan pemrosesan pesan yang andal, atur batas waktu visibilitas menjadi lebih lama dari batas waktu baca AWS SDK. Ini berlaku saat menggunakan [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API dengan polling pendek dan polling panjang. Batas waktu visibilitas yang lebih lama mencegah pesan tersedia bagi konsumen lain sebelum permintaan asli selesai, mengurangi risiko pemrosesan duplikat.
# Menggunakan ID grup pesan dengan Amazon SQS FIFO Queues
Dalam antrian FIFO (First-In-First-Out), [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)adalah atribut yang mengatur pesan ke dalam grup yang berbeda. Pesan dalam grup pesan yang sama selalu diproses satu per satu, dalam urutan yang ketat, memastikan bahwa tidak ada dua pesan dari grup yang sama yang diproses secara bersamaan. Dalam antrian standar, menggunakan `MessageGroupId` memungkinkan antrian yang [adil](sqs-fair-queues.md). Jika pemesanan ketat diperlukan, gunakan antrian FIFO.
**Topics**
+ [Menginterleaving beberapa grup pesan yang dipesan di Amazon SQS](interleaving-multiple-ordered-message-groups.md)
+ [Mencegah pemrosesan duplikat dalam sistem multi-produsen/konsumen di Amazon SQS](avoding-processing-duplicates-in-multiple-producer-consumer-system.md)
+ [Hindari backlog pesan besar dengan ID grup pesan yang sama di Amazon SQS](avoid-backlog-with-the-same-message-group-id.md)
+ [Hindari menggunakan kembali ID grup pesan yang sama dengan antrian virtual di Amazon SQS](avoiding-reusing-message-group-id-with-virtual-queues.md)
# Menginterleaving beberapa grup pesan yang dipesan di Amazon SQS
Untuk menginterleave beberapa grup pesan yang diurutkan dalam satu antrian FIFO, tetapkan a [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)ke setiap grup (misalnya, data sesi untuk pengguna yang berbeda). Hal ini memungkinkan beberapa konsumen untuk membaca dari antrian secara bersamaan sambil memastikan bahwa pesan dalam grup yang sama diproses secara berurutan.
Ketika pesan dengan spesifik `MessageGroupId` sedang diproses dan tidak terlihat, tidak ada konsumen lain yang dapat memproses pesan dari grup yang sama hingga batas waktu visibilitas berakhir atau pesan dihapus.
# Mencegah pemrosesan duplikat dalam sistem multi-produsen/konsumen di Amazon SQS
Dalam sistem throughput tinggi, latensi rendah di mana pemesanan pesan bukan prioritas, produsen dapat menetapkan unik untuk setiap pesan. [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) Ini memastikan bahwa antrian Amazon SQS FIFO menghilangkan duplikat, bahkan dalam pengaturan multi-produsen/multi-konsumen. Meskipun pendekatan ini mencegah pesan duplikat, itu tidak menjamin pemesanan pesan karena setiap pesan diperlakukan sebagai grup independennya sendiri.
Dalam sistem apa pun dengan banyak produsen dan konsumen, selalu ada risiko pengiriman duplikat. Jika konsumen gagal memproses pesan sebelum batas waktu visibilitas berakhir, Amazon SQS membuat pesan tersebut tersedia kembali, berpotensi memungkinkan konsumen lain untuk mengambilnya. Untuk mengurangi hal ini, pastikan pengaturan batas waktu pemberitahuan dan visibilitas pesan yang tepat berdasarkan waktu pemrosesan.
# Hindari backlog pesan besar dengan ID grup pesan yang sama di Amazon SQS
Antrian FIFO mendukung maksimal 120.000 pesan dalam penerbangan (pesan yang diterima oleh konsumen tetapi belum dihapus). Jika batas ini tercapai, Amazon SQS tidak mengembalikan kesalahan, tetapi pemrosesan mungkin terpengaruh. Anda dapat meminta peningkatan di luar batas ini dengan menghubungi [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html).
Antrian FIFO memindai 120.000 pesan pertama untuk menentukan grup pesan yang tersedia. Jika backlog besar terbentuk dalam satu grup pesan, pesan dari grup lain yang dikirim nanti akan tetap diblokir hingga backlog diproses.
**catatan**
Backlog pesan dapat terjadi ketika konsumen berulang kali gagal memproses pesan. Ini bisa disebabkan oleh masalah konten pesan atau kegagalan sisi konsumen. Untuk mencegah penundaan pemrosesan pesan, konfigurasikan [antrian huruf mati](sqs-dead-letter-queues.md) untuk memindahkan pesan yang belum diproses setelah beberapa upaya gagal. Ini memastikan bahwa pesan lain dalam grup pesan yang sama dapat diproses, mencegah kemacetan sistem.
# Hindari menggunakan kembali ID grup pesan yang sama dengan antrian virtual di Amazon SQS
Saat menggunakan antrian virtual dengan antrian host bersama, hindari menggunakan kembali antrian virtual yang berbeda [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html). Jika beberapa antrian virtual berbagi antrian host yang sama dan berisi pesan yang sama`MessageGroupId`, pesan tersebut dapat memblokir satu sama lain, mencegah pemrosesan yang efisien. Untuk memastikan pemrosesan pesan yang lancar, tetapkan `MessageGroupId` nilai unik untuk pesan dalam antrian virtual yang berbeda.
# Menggunakan ID percobaan permintaan terima Amazon SQS
ID percobaan permintaan terima adalah token unik yang digunakan untuk menghapus duplikasi [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)panggilan di Amazon SQS. Selama pemadaman jaringan atau masalah konektivitas antara aplikasi Anda dan Amazon SQS, praktik terbaik adalah:
+ Berikan ID percobaan permintaan terima saat melakukan `ReceiveMessage` panggilan.
+ Coba lagi menggunakan ID percobaan permintaan terima yang sama jika operasi gagal.
# 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.