Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pola desain praktik terbaik: mengoptimalkan performa Amazon S3
Aplikasi Anda dapat dengan mudah mencapai ribuan transaksi per detik dalam performa permintaan saat mengunggah dan mengambil penyimpanan dari Amazon S3. Amazon S3 secara otomatis menyesuaikan ke tingkat permintaan yang tinggi. Misalnya, aplikasi Anda dapat mencapai setidaknya 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD permintaan per detik per awalan Amazon S3 yang dipartisi. Tidak ada batas jumlah prefiks dalam bucket. Anda dapat meningkatkan performa membaca atau menulis dengan menggunakan paralelisasi. Misalnya, jika Anda membuat 10 prefiks dalam bucket Amazon S3 untuk paralelisasi bacaan, Anda dapat menskalakan performa baca Anda menjadi 55.000 permintaan baca per detik. Demikian pula, Anda dapat menskalakan operasi tulis dengan menulis ke beberapa prefiks. Penskalaan, dalam kasus operasi baca dan tulis, terjadi secara bertahap dan tidak instan, dan kinerja aktual akan bervariasi berdasarkan karakteristik beban kerja spesifik Anda, pola penggunaan, dan konfigurasi sistem. Sementara Amazon S3 menskalakan ke tingkat permintaan baru Anda yang lebih tinggi, Anda mungkin melihat beberapa kesalahan 503 (Perlambat). Kesalahan ini akan hilang saat penskalaan selesai. Untuk informasi selengkapnya tentang cara membuat dan menggunakan prefiks, lihat [Organisasi objek menggunakan prefiks](using-prefixes.md).
Beberapa aplikasi danau data di Amazon S3 memindai jutaan atau miliar objek untuk kueri yang berjalan di atas petabyte data. Aplikasi data lake ini mencapai kecepatan transfer instans tunggal yang memaksimalkan penggunaan antarmuka jaringan untuk instans [Amazon](https://docs.aws.amazon.com/ec2/index.html) EC2 mereka, yang dapat mencapai hingga Gb/s 100 pada satu instance. Aplikasi ini kemudian menggabungkan throughput di beberapa instans untuk mendapatkan beberapa terabit per detik.
Aplikasi lain sensitif terhadap latensi, seperti aplikasi perpesanan media sosial. Aplikasi ini dapat mencapai latensi objek kecil yang konsisten (dan first-byte-out latensi untuk objek yang lebih besar) sekitar 100-200 milidetik.
AWS Layanan lain juga dapat membantu mempercepat kinerja untuk arsitektur aplikasi yang berbeda. Misalnya, jika Anda menginginkan laju transfer yang lebih tinggi pada koneksi HTTP tunggal atau latensi milidetik digit, gunakan [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) atau [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) untuk menyimpan cache dengan Amazon S3.
Selain itu, jika Anda ingin transportasi data cepat melalui jarak jauh antara klien dan bucket S3, gunakan [Mengonfigurasi transfer file yang cepat dan aman menggunakan Amazon S3 Transfer Acceleration](transfer-acceleration.md). Transfer Acceleration menggunakan lokasi tepi yang didistribusikan secara global CloudFront untuk mempercepat transportasi data melalui jarak geografis. Jika beban kerja Amazon S3 Anda menggunakan enkripsi sisi server AWS KMS, lihat [AWS KMS Batas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) di Panduan AWS Key Management Service Pengembang untuk informasi tentang tarif permintaan yang didukung untuk kasus penggunaan Anda.
Topik berikut menjelaskan panduan praktik terbaik dan pola desain untuk mengoptimalkan performa aplikasi yang menggunakan Amazon S3. Lihat [Pedoman kinerja untuk Amazon S3](optimizing-performance-guidelines.md) dan [Pola desain kinerja untuk Amazon S3](optimizing-performance-design-patterns.md) untuk informasi terkini tentang optimalisasi performa untuk Amazon S3.
**catatan**
Untuk informasi selengkapnya tentang menggunakan kelas penyimpanan Amazon S3 Express One Zone dengan bucket direktori, lihat [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone) dan [Bekerja dengan bucket direktori](directory-buckets-overview.md).
**Topics**
+ [Pedoman kinerja untuk Amazon S3](optimizing-performance-guidelines.md)
+ [Pola desain kinerja untuk Amazon S3](optimizing-performance-design-patterns.md)
# Pedoman kinerja untuk Amazon S3
Ketika membangun aplikasi yang mengunggah dan mengambil objek dari Amazon S3, ikuti panduan praktik terbaik kami untuk mengoptimalkan performa. Kami juga menawarkan [Pola desain kinerja untuk Amazon S3 ](optimizing-performance-design-patterns.md) yang lebih terperinci.
Untuk mendapatkan performa terbaik untuk aplikasi Anda di Amazon S3, kami merekomendasikan panduan berikut ini.
**Topics**
+ [
## Ukur performa
](#optimizing-performance-guidelines-measure)
+ [
## Skalakan koneksi penyimpanan secara horizontal
](#optimizing-performance-guidelines-scale)
+ [
## Gunakan pengambilan rentang byte
](#optimizing-performance-guidelines-get-range)
+ [
## Permintaan coba lagi untuk aplikasi yang sensitif latensi
](#optimizing-performance-guidelines-retry)
+ [
## Gabungkan Amazon S3 (Penyimpanan) dan Amazon EC2 (komputasi) dalam hal yang sama Wilayah AWS
](#optimizing-performance-guidelines-combine)
+ [
## Gunakan Amazon S3 Transfer Acceleration untuk meminimalkan latensi yang disebabkan oleh jarak
](#optimizing-performance-guidelines-acceleration)
+ [
## Gunakan versi terbaru dari AWS SDKs
](#optimizing-performance-guidelines-sdk)
## Ukur performa
Ketika mengoptimalkan performa, lihat kebutuhan throughput jaringan, CPU, dan DRAM. Bergantung pada perpaduan permintaan untuk sumber daya yang berbeda ini, mungkin akan untuk mengevaluasi berbagai jenis instans [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html). Untuk informasi selengkapnya tentang jenis instans, lihat [Jenis Instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) di *Panduan Pengguna Amazon EC2*.
Ini juga membantu untuk melihat waktu pencarian DNS, latensi, dan kecepatan transfer data menggunakan alat analisis HTTP saat mengukur performa.
Untuk memahami persyaratan performa dan mengoptimalkan performa aplikasi Anda, Anda juga dapat memantau respons kesalahan 503 yang Anda terima. Memantau metrik performa tertentu dapat menimbulkan biaya tambahan. Untuk informasi selengkapnya, lihat [Harga Amazon S3](https://aws.amazon.com/s3/pricing/).
### Pantau jumlah respons kesalahan status 503 (Perlambat)
Untuk memantau jumlah respons kesalahan status 503 yang Anda dapatkan, Anda dapat menggunakan salah satu opsi berikut:
+ Gunakan metrik CloudWatch permintaan Amazon untuk Amazon S3. Metrik CloudWatch permintaan menyertakan metrik untuk respons status 5xx. Untuk informasi selengkapnya tentang metrik CloudWatch permintaan, lihat[Memantau metrik dengan Amazon CloudWatch](cloudwatch-monitoring.md).
+ Gunakan jumlah kesalahan 503 (Layanan Tidak Tersedia) yang tersedia di bagian metrik lanjutan Lensa Penyimpanan Amazon S3. Untuk informasi selengkapnya, lihat [Menggunakan metrik Lensa Penyimpanan S3 untuk meningkatkan kinerja](storage-lens-detailed-status-code.md).
+ Gunakan pencatatan log akses server Amazon S3. Dengan pencatatan akses server, Anda dapat memfilter dan meninjau semua permintaan yang menerima respons 503 (Kesalahan Internal). Anda juga dapat menggunakan Amazon Athena untuk mengurai log. Untuk informasi selengkapnya tentang pencatatan log akses server, lihat [Pencatatan permintaan dengan pencatatan akses server](ServerLogs.md).
Dengan memantau jumlah kode kesalahan status HTTP 503, Anda sering kali dapat memperoleh wawasan berharga tentang prefiks, kunci, atau bucket mana yang mendapatkan permintaan throttling paling banyak.
## Skalakan koneksi penyimpanan secara horizontal
Menyebarkan permintaan di berbagai koneksi adalah pola desain umum untuk menskalakan performa secara horizontal. Ketika Anda membangun aplikasi berperforma tinggi, bayangkan Amazon S3 sebagai sistem terdistribusi yang sangat besar, bukan sebagai titik akhir jaringan tunggal seperti server penyimpanan tradisional. Anda dapat mencapai performa terbaik dengan mengeluarkan beberapa permintaan sekaligus ke Amazon S3. Sebarkan permintaan ini melalui koneksi terpisah untuk memaksimalkan bandwidth yang dapat diakses dari Amazon S3. Amazon S3 tidak memiliki batas untuk jumlah koneksi yang dilakukan ke bucket Anda.
## Gunakan pengambilan rentang byte
Menggunakan Header HTTP `Range` di permintaan [GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html), Anda dapat mengambil rentang byte dari objek, dengan hanya mentransfer bagian tertentu. Anda dapat menggunakan koneksi bersamaan ke Amazon S3 untuk mengambil byte yang berbeda dari dalam objek yang sama. Ini membantu Anda mencapai throughput agregat yang lebih tinggi dibandingkan permintaan objek utuh tunggal. Pengambilan rentang objek besar yang lebih kecil juga memungkinkan aplikasi Anda untuk meningkatkan waktu coba kembali ketika permintaan terganggu. Untuk informasi selengkapnya, lihat [Mengunggah objek](download-objects.md).
Jika objek adalah PUT yang menggunakan pengunggahan multibagian, praktik yang baik adalah GET dalam ukuran bagian yang sama (atau setidaknya sejajar dengan batas bagian) untuk performa terbaik. Permintaan GET dapat secara langsung menangani bagian individual; misalnya, `GET ?partNumber=N.`
## Permintaan coba lagi untuk aplikasi yang sensitif latensi
Batas waktu dan percobaan ulang yang agresif membantu mendorong latensi yang konsisten. Mengingat skala besar Amazon S3, jika permintaan pertama berjalan lambat, permintaan yang dicoba kembali kemungkinan besar mengambil jejak yang berbeda dan dengan cepat berhasil. AWS SDKs Memiliki batas waktu yang dapat dikonfigurasi dan nilai coba lagi yang dapat Anda sesuaikan dengan toleransi aplikasi spesifik Anda.
## Gabungkan Amazon S3 (Penyimpanan) dan Amazon EC2 (komputasi) dalam hal yang sama Wilayah AWS
Meskipun nama bucket S3 bersifat unik secara global, setiap bucket disimpan di Wilayah yang Anda pilih saat membuat bucket. Untuk mempelajari lebih lanjut tentang pedoman penamaan bucket, lihat [Ikhtisar bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) [dan aturan penamaan Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html). Untuk mengoptimalkan kinerja, sebaiknya Anda mengakses bucket dari instans Amazon EC2 secara bersamaan Wilayah AWS jika memungkinkan. Ini membantu mengurangi latensi jaringan dan biaya transfer data.
Untuk informasi lebih lanjut tentang biaya transfer data, lihat [Harga Amazon S3](https://aws.amazon.com/s3/pricing/).
## Gunakan Amazon S3 Transfer Acceleration untuk meminimalkan latensi yang disebabkan oleh jarak
[Mengonfigurasi transfer file yang cepat dan aman menggunakan Amazon S3 Transfer Acceleration](transfer-acceleration.md) mengelola transfer file yang cepat, mudah, dan aman dalam jarak geografis yang panjang antara klien dan bucket S3. Transfer Acceleration memanfaatkan lokasi edge yang didistribusikan secara global di [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html). Saat data tiba di lokasi edge, data diarahkan ke Amazon S3 melalui jalur jaringan yang dioptimalkan. Transfer Acceleration ideal untuk mentransfer gigabyte ke terabyte data secara teratur melintasi benua. Ini juga berguna bagi klien yang mengunggah ke bucket terpusat dari seluruh dunia.
Anda dapat menggunakan alat [perbandingan Amazon S3 Transfer Acceleration Speed untuk membandingkan kecepatan](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html) unggah yang dipercepat dan tidak dipercepat di seluruh Wilayah Amazon S3. Alat Speed Comparison menggunakan unggahan multibagian untuk mentransfer file dari browser Anda ke berbagai Wilayah Amazon S3 dengan dan tanpa menggunakan Amazon S3 Transfer Acceleration.
## Gunakan versi terbaru dari AWS SDKs
Ini AWS SDKs menyediakan dukungan bawaan untuk banyak pedoman yang direkomendasikan untuk mengoptimalkan kinerja Amazon S3. SDKs Menyediakan API yang lebih sederhana untuk memanfaatkan Amazon S3 dari dalam aplikasi dan diperbarui secara berkala untuk mengikuti praktik terbaik terbaru. Misalnya, logika SDKs sertakan untuk mencoba ulang permintaan secara otomatis pada kesalahan HTTP 503 dan berinvestasi dalam kode untuk merespons dan beradaptasi dengan koneksi yang lambat.
Ini SDKs juga menyediakan [Manajer Transfer](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3-transfermanager.html), yang mengotomatiskan koneksi penskalaan horizontal untuk mencapai ribuan permintaan per detik, menggunakan permintaan rentang byte jika sesuai. Sangat penting untuk menggunakan versi terbaru dari AWS SDKs untuk mendapatkan fitur optimasi kinerja terbaru.
Anda juga dapat mengoptimalkan performa saat Anda menggunakan permintaan API REST HTTP. Saat menggunakan REST API, Anda harus mengikuti praktik terbaik yang sama yang merupakan bagian dari SDKs. Izinkan batas waktu dan percobaan ulang pada permintaan yang lambat, dan beberapa koneksi untuk memungkinkan pengambilan data objek secara paralel. Untuk informasi selengkapnya tentang API REST, lihat [Referensi API Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
# Pola desain kinerja untuk Amazon S3
Saat merancang aplikasi untuk mengunggah dan mengambil objek dari Amazon S3, gunakan pola desain praktik terbaik kami untuk mencapai performa terbaik untuk aplikasi Anda. Kami juga menawarkan [Pedoman kinerja untuk Amazon S3 ](optimizing-performance-guidelines.md) untuk Anda pertimbangkan saat sedang merencanakan arsitektur aplikasi Anda.
Untuk mengoptimalkan performa, Anda dapat menggunakan pola desain berikut.
**Topics**
+ [
## Menggunakan caching untuk konten yang sering diakses
](#optimizing-performance-caching)
+ [
## Batas waktu dan percobaan ulang untuk aplikasi yang sensitif terhadap latensi
](#optimizing-performance-timeouts-retries)
+ [
## Penskalaan horizontal dan paralelisasi permintaan untuk throughput tinggi
](#optimizing-performance-parallelization)
+ [
## Menggunakan Amazon S3 Transfer Acceleration untuk mempercepat transfer data yang berbeda secara geografis
](#optimizing-performance-acceleration)
+ [
## Mengoptimalkan beban kerja tingkat permintaan tinggi
](#optimizing-performance-high-request-rate)
## Menggunakan caching untuk konten yang sering diakses
Banyak aplikasi yang menyimpan data di Amazon S3 melayani “set kerja” data yang berulang kali diminta oleh pengguna. Jika beban kerja mengirimkan permintaan GET berulang untuk sekumpulan objek umum, Anda dapat menggunakan cache seperti [Amazon CloudFront, [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html)](https://docs.aws.amazon.com/cloudfront/index.html), atau [AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/index.html)untuk mengoptimalkan kinerja. Penerapan cache yang berhasil dapat menghasilkan latensi rendah dan laju transfer data tinggi. Aplikasi yang menggunakan caching juga mengirimkan lebih sedikit permintaan langsung ke Amazon S3, yang dapat membantu mengurangi biaya permintaan.
Amazon CloudFront adalah jaringan pengiriman konten cepat (CDN) yang secara transparan menyimpan data dari Amazon S3 dalam satu set besar titik kehadiran yang didistribusikan secara geografis (). PoPs Ketika objek dapat diakses dari beberapa Wilayah, atau melalui internet, CloudFront memungkinkan data untuk di-cache dekat dengan pengguna yang mengakses objek. Ini dapat menghasilkan pengiriman konten Amazon S3 populer dengan performa tinggi. Untuk selengkapnya CloudFront, lihat [Panduan CloudFront Pengembang Amazon](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/).
Amazon ElastiCache adalah cache dalam memori yang dikelola. Dengan ElastiCache, Anda dapat menyediakan instans Amazon EC2 yang menyimpan objek cache dalam memori. Hasil caching ini menghasilkan urutan pengurangan besar-besaran dalam latensi GET dan peningkatan substansial dalam throughput unduhan. Untuk menggunakannya ElastiCache, Anda memodifikasi logika aplikasi untuk mengisi cache dengan objek panas dan memeriksa cache untuk objek panas sebelum memintanya dari Amazon S3. Untuk contoh penggunaan ElastiCache untuk meningkatkan kinerja Amazon S3 GET, lihat posting blog [Turbocharge Amazon S3 dengan Amazon untuk Redis](https://aws.amazon.com/blogs/storage/turbocharge-amazon-s3-with-amazon-elasticache-for-redis/). ElastiCache
AWS Elemental MediaStore adalah sistem caching dan distribusi konten yang khusus dibuat untuk alur kerja video dan pengiriman media dari Amazon S3. MediaStore menyediakan end-to-end penyimpanan APIs khusus untuk video, dan direkomendasikan untuk beban kerja video yang sensitif terhadap kinerja. Untuk selengkapnya MediaStore, lihat [Panduan AWS Elemental MediaStore Pengguna](https://docs.aws.amazon.com/mediastore/latest/ug/).
## Batas waktu dan percobaan ulang untuk aplikasi yang sensitif terhadap latensi
Ada situasi tertentu ketika aplikasi menerima respons dari Amazon S3 yang menunjukkan bahwa percobaan ulang diperlukan. Bucket peta Amazon S3 dan nama objek ke data objek yang terkait dengannya. Jika aplikasi menghasilkan tingkat permintaan yang tinggi (biasanya tingkat permintaan lebih dari 5.000 permintaan per detik ke sejumlah kecil objek), aplikasi mungkin akan menerima respons *perlambatan* HTTP 503. Jika kesalahan ini terjadi, setiap SDK AWS menerapkan logika percobaan ulang otomatis menggunakan mundur eksponensial. Jika Anda tidak menggunakan SDK AWS , Anda harus menerapkan logika percobaan ulang saat menerima kesalahan HTTP 503. Untuk informasi tentang teknik back-off, lihat [Coba lagi perilaku](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) di Panduan Referensi Alat *AWS SDKs dan Alat*.
Amazon S3 secara otomatis menskalakan dalam menanggapi tingkat permintaan baru yang berkelanjutan, secara dinamis mengoptimalkan performa. Meskipun Amazon S3 secara internal mengoptimalkan untuk tingkat permintaan baru, Anda akan menerima respons permintaan HTTP 503 secara sementara hingga optimalisasi selesai. Setelah Amazon S3 secara internal mengoptimalkan performa untuk tingkat permintaan baru, semua permintaan umumnya dilayani tanpa percobaan ulang.
Untuk aplikasi sensitif latensi, Amazon S3 menyarankan pelacakan dan mencoba kembali operasi yang lebih lambat secara agresif. Saat Anda mencoba lagi permintaan, kami menyarankan menggunakan koneksi baru ke Amazon S3 dan melakukan pencarian DNS baru.
Saat Anda membuat permintaan berukuran besar (misalnya, lebih dari 128 MB), kami menyarankan untuk melacak throughput yang dicapai, dan mencoba kembali 5 persen paling lambat dari permintaan tersebut. Saat Anda membuat permintaan yang lebih kecil (misalnya, kurang dari 512 KB), yaitu latensi median sering kali berada dalam rentang milidetik, panduan yang baik adalah mencoba kembali operasi GET atau PUT setelah 2 detik. Jika percobaan ulang tambahan diperlukan, praktik terbaik adalah back off. Misalnya, kami sarankan untuk mengeluarkan satu percobaan ulang setelah 2 detik dan percobaan ulang kedua setelah 4 detik tambahan.
Jika aplikasi Anda membuat permintaan ukuran tetap ke Amazon S3, Anda akan mengharapkan waktu respons yang lebih konsisten untuk setiap permintaan ini. Dalam kasus ini, strategi sederhana adalah mengidentifikasi 1 persen permintaan paling lambat dan mencobanya lagi. Bahkan, satu kali coba ulang sering kali efektif dalam mengurangi latensi.
Jika Anda menggunakan AWS Key Management Service (AWS KMS) untuk enkripsi sisi server, lihat [Kuota](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) di *Panduan AWS Key Management Service Pengembang* untuk informasi tentang tarif permintaan yang didukung untuk kasus penggunaan Anda.
## Penskalaan horizontal dan paralelisasi permintaan untuk throughput tinggi
Amazon S3 adalah sistem terdistribusi yang sangat besar. Untuk membantu Anda memanfaatkan skalanya, kami mendorong Anda untuk menskalakan permintaan paralel secara horizontal ke titik akhir layanan Amazon S3. Selain mendistribusikan permintaan di dalam Amazon S3, jenis pendekatan penskalaan ini membantu mendistribusikan muatan melalui beberapa jejak melalui jaringan.
Untuk transfer dengan throughput tinggi, Amazon S3 menyarankan penggunaan aplikasi yang menggunakan beberapa koneksi untuk GET atau PUT data secara paralel. Misalnya, ini didukung oleh [Amazon S3 Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html) di AWS Java SDK, dan sebagian besar lainnya AWS SDKs menyediakan konstruksi serupa. Untuk beberapa aplikasi, Anda dapat mencapai koneksi paralel dengan meluncurkan beberapa permintaan secara bersamaan dalam utas aplikasi yang berbeda, atau dalam instans aplikasi yang berbeda. Pendekatan terbaik untuk diambil tergantung pada aplikasi Anda dan struktur objek yang Anda akses.
Anda dapat menggunakan AWS SDKs untuk mengeluarkan permintaan GET dan PUT secara langsung daripada menggunakan manajemen transfer di AWS SDK. Dengan pendekatan ini, Anda dapat mengatur beban kerja secara lebih langsung, sembari tetap memanfaatkan dukungan SDK untuk percobaan ulang dan penanganannya terhadap setiap respons HTTP 503 yang mungkin terjadi. Sebagai aturan umum, saat Anda mengunduh objek besar dari Amazon S3, kami sarankan untuk membuat permintaan bersamaan untuk memaksimalkan throughput jaringan dan mengoptimalkan kinerja unduhan. Anda dapat mencapai ini dengan meminta rentang byte tertentu dari objek atau mengunduh bagian-bagian individual dari objek multipart secara bersamaan. Pendekatan unduhan paralel ini membantu sepenuhnya memanfaatkan kapasitas kartu antarmuka jaringan (NIC) Anda. Untuk objek yang diunggah menggunakan unggahan multibagian, kami sarankan untuk mengunduhnya menggunakan ukuran bagian yang sama atau menyelaraskan permintaan ke batas bagian asli untuk kinerja terbaik. Metode pengunduhan bersamaan ini memberikan throughput agregat yang lebih tinggi dibandingkan dengan permintaan seluruh objek tunggal.
Mengukur performa sangat penting saat Anda menyesuaikan jumlah permintaan untuk masalah secara bersamaan. Kami menyarankan untuk memulai dengan permintaan tunggal pada satu waktu. Mengukur bandwith jaringan yang dicapai dan penggunaan sumber daya lain yang digunakan aplikasi Anda dalam memproses data. Anda kemudian dapat mengidentifikasi sumber daya bottleneck (yaitu, sumber daya dengan penggunaan tertinggi), dan karenanya jumlah permintaan yang mungkin berguna. Misalnya, jika memproses satu permintaan pada satu waktu menghasilkan penggunaan CPU sebesar 25 persen, hal ini menunjukkan bahwa hingga empat permintaan bersamaan dapat diakomodasi. Pengukuran sangat penting, dan perlu mengonfirmasi penggunaan sumber daya karena tingkat permintaan meningkat.
Jika aplikasi Anda menerbitkan permintaan secara langsung ke Amazon S3 menggunakan API REST, kami menyarankan menggunakan kumpulan koneksi HTTP dan menggunakan kembali setiap koneksi untuk serangkaian permintaan. Menghindari penyiapan koneksi per permintaan menghilangkan kebutuhan untuk menjalankan TCP slow-start dan handshake Secure Sockets Layer (SSL) pada setiap permintaan. Untuk informasi selengkapnya tentang API REST, lihat [Referensi API Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
Terakhir, penting untuk memperhatikan DNS dan pemeriksaan ulang bahwa permintaan tersebar di sejumlah besar alamat IP Amazon S3. Kueri DNS untuk siklus Amazon S3 melalui daftar besar titik akhir IP. Namun pemecah cache atau kode aplikasi yang menggunakan kembali satu alamat IP tidak mendapatkan keuntungan dari keragaman alamat dan load balancing yang mengikutinya. Alat utilitas jaringan seperti alat baris perintah `netstat` dapat menunjukkan alamat IP yang digunakan untuk komunikasi dengan Amazon S3, dan kami memberikan panduan untuk konfigurasi DNS untuk digunakan. Untuk informasi selengkapnya tentang pedoman ini, lihat [Membuat permintaan](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html) di Referensi *API Amazon S3*.
## Menggunakan Amazon S3 Transfer Acceleration untuk mempercepat transfer data yang berbeda secara geografis
[Mengonfigurasi transfer file yang cepat dan aman menggunakan Amazon S3 Transfer Acceleration](transfer-acceleration.md) terbukti efektif dalam meminimalkan atau menghilangkan latensi yang disebabkan oleh jarak geografis antara klien yang tersebar secara global dan aplikasi regional menggunakan Amazon S3. Transfer Acceleration menggunakan lokasi edge yang didistribusikan secara global CloudFront untuk transportasi data. Jaringan AWS edge memiliki titik kehadiran di lebih dari 50 lokasi. Saat ini, digunakan untuk mendistribusikan konten melalui CloudFront dan untuk memberikan respons cepat terhadap kueri DNS yang dibuat ke [Amazon Route 53](https://docs.aws.amazon.com/route53/index.html).
Jaringan edge juga membantu mempercepat transfer data masuk dan keluar dari Amazon S3. Sangat ideal untuk aplikasi yang mentransfer data antar benua, memiliki koneksi internet yang cepat, menggunakan objek besar, atau memiliki banyak konten untuk diunggah. Saat datanya tiba di lokasi edge, data diarahkan ke Amazon S3 melalui jalur jaringan yang dioptimalkan. Secara umum, semakin jauh Anda berada di Wilayah Amazon S3, semakin tinggi peningkatan kecepatan yang dapat Anda harapkan dari penggunaan Transfer Acceleration.
Anda dapat mengatur Transfer Acceleration pada bucket baru atau yang sudah ada. Anda dapat menggunakan endpoint Amazon S3 Transfer Acceleration terpisah untuk menggunakan lokasi AWS tepi. Cara terbaik untuk menguji apakah Transfer Acceleration membantu klien meminta performa adalah menggunakan [Alat Amazon S3 Transfer Acceleration Speed Comparison](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html). Konfigurasi dan kondisi jaringan bervariasi dari waktu ke waktu dan dari lokasi ke lokasi. Jadi, Anda hanya dikenakan biaya untuk transfer ketika Amazon S3 Transfer Acceleration dapat meningkatkan performa pengunggahan Anda. Untuk informasi tentang penggunaan Akselerasi Transfer dengan yang berbeda AWS SDKs, lihat[Mengaktifkan dan menggunakan S3 Transfer Acceleration](transfer-acceleration-examples.md).
## Mengoptimalkan beban kerja tingkat permintaan tinggi
Aplikasi yang menghasilkan tingkat permintaan tinggi ke Amazon S3 memerlukan pola desain khusus untuk mencapai kinerja yang optimal. Jika aplikasi Anda secara konsisten menghasilkan lebih dari 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD permintaan per detik per awalan, Anda harus menerapkan strategi untuk mendistribusikan permintaan dan menangani perilaku penskalaan.
Amazon S3 secara otomatis menskalakan untuk mengakomodasi tingkat permintaan yang lebih tinggi, tetapi penskalaan ini terjadi secara bertahap. Selama proses penskalaan, Anda mungkin menerima respons HTTP 503 (Slow Down). Tanggapan ini bersifat sementara dan menunjukkan bahwa Amazon S3 mengoptimalkan sistem internalnya untuk pola permintaan baru Anda. Setelah penskalaan selesai, permintaan Anda akan dilayani tanpa pembatasan.
Untuk mengoptimalkan kinerja beban kerja tingkat permintaan tinggi, pertimbangkan strategi berikut:
+ **Mendistribusikan permintaan di beberapa awalan** — Gunakan pola awalan acak atau berurutan untuk menyebarkan permintaan di beberapa partisi. Misalnya, alih-alih menggunakan nama objek berurutan seperti`log-2024-01-01.txt`, gunakan awalan acak seperti. `a1b2/log-2024-01-01.txt` Ini membantu Amazon S3 mendistribusikan beban dengan lebih efektif.
+ **Terapkan backoff eksponensial untuk kesalahan 503 — Saat Anda menerima respons HTTP 503**, terapkan logika coba lagi dengan backoff eksponensial. Mulailah dengan penundaan singkat dan secara bertahap tingkatkan waktu tunggu di antara percobaan ulang. Logika coba ulang bawaan yang menangani ini secara otomatis. AWS SDKs
+ **Pantau pola permintaan** — Gunakan CloudWatch metrik Amazon untuk memantau tingkat permintaan dan tingkat kesalahan Anda. Berikan perhatian khusus pada metrik kesalahan 5xx, yang dapat menunjukkan kapan aplikasi Anda mendekati atau melebihi batas penskalaan saat ini.
+ **Tingkatkan tingkat permintaan secara bertahap** — Saat meluncurkan aplikasi baru atau meningkatkan tingkat permintaan secara signifikan, tingkatkan lalu lintas Anda secara bertahap dari waktu ke waktu daripada langsung melompat ke tingkat puncak. Ini memungkinkan Amazon S3 untuk menskalakan secara proaktif dan mengurangi kemungkinan pelambatan.
+ **Gunakan beberapa koneksi** — Mendistribusikan permintaan Anda di beberapa koneksi HTTP untuk memaksimalkan throughput dan mengurangi dampak masalah koneksi tunggal.
Untuk aplikasi yang membutuhkan kinerja tinggi yang konsisten, pertimbangkan untuk menggunakan Amazon S3 Express One Zone, yang dirancang untuk aplikasi yang memerlukan latensi milidetik satu digit dan dapat mendukung ratusan ribu permintaan per detik. Untuk informasi selengkapnya, lihat [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone).