Throughput On-Demand DynamoDB: Diukur
Berapa banyak throughput yang didapat tabel on-demand DynamoDB yang baru?
Tabel yang benar-benar baru melayani sekitar 4,130 penulisan per detik — AWS mendokumentasikan 4,000 — dan setidaknya 12,700 pembacaan eventually-consistent per detik. Kami mengukur keduanya pada 2026-08-27 terhadap tabel yang baru dibuat beberapa menit sebelumnya: penulisan menempel di 4,130 ±2/detik di seluruh beban di atas baseline yang kami berikan, dan pembacaan sama sekali tidak pernah di-throttle sebelum generator beban kami sendiri kehabisan daya.
Kedua angka itu, dan segala sesuatu yang lain di halaman ini, berasal dari menghitung request nyata terhadap layanan live — bukan dari menuliskan ulang dokumentasi. Metode, data mentah, dan tiga percobaan yang gagal ditulis di cerita benchmark-nya; halaman ini adalah referensi tempat angka-angka itu bermukim.
Plafon tulis pada tabel baru
Beban yang ditawarkan dinaikkan bertahap dalam jendela 30 detik terhadap tabel yang belum pernah menerima trafik. Setiap request membawa item ~1 KB dengan key acak seragam — tidak ada yang terlibat:
| Ditawarkan (penulisan/s) | Tercapai | Request ter-throttle |
|---|---|---|
| 1,000 | 1,000 | 0 |
| 2,000 | 2,000 | 0 |
| 3,000 | 3,000 | 0 |
| 4,000 | 4,000 | 0 |
| 5,000 | 4,132 | 25,992 |
| 6,000 | 4,131 | 55,966 |
| 8,000 | 4,134 | 115,922 |
Baseline 4,000 penulisan/detik yang terdokumentasi bertahan, dengan sekitar 3% ruang lebih di atasnya. Plafonnya rata secara mengejutkan: 4,132, 4,131, 4,134 tercapai per detik pada 5,000, 6,000, dan 8,000 yang ditawarkan. Latensi tidak memburuk saat Anda melewatinya — latensi tulis p50 tetap di 4–5 ms in-region di setiap jendela. Layanan ini tidak melambat; ia menolak.
Apa yang sebenarnya dikembalikan oleh throttle
Penolakan pertama tiba 0.9–3.8 detik ke dalam setiap jendela di atas baseline (makin tinggi rate yang ditawarkan, makin cepat ia datang). Verbatim:
ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.htmlAda dua hal untuk direncanakan. Ini adalah HTTP 400, bukan 5xx — kebijakan retry atau alarm yang hanya mengawasi 5xx akan luput sepenuhnya dari throttling on-demand (SDK memang me-retry-nya secara default; lihat ). Dan petunjuk hot-key adalah saran default, bukan diagnosis — key kami acak seragam, jadi pada skala kecil tersangka pertama untuk pesan ini adalah plafon level-tabel, bukan skema key Anda. Empat penyebab throttling yang berbeda punya panduannya sendiri.
Plafon baca
Pembacaan berjalan terhadap tabel baru kedua yang diisi 1,000 item, sebagai
GetItem (~1 KB, masing-masing
0.5 read unit):
| Ditawarkan (pembacaan/s) | Tercapai | Request ter-throttle |
|---|---|---|
| 4,000 | 4,000 | 0 |
| 8,000 | 7,941 | 0 |
| 12,000 | 11,119 | 0 |
| 16,000 | 12,762 | 0 |
Nol throttle di setiap rate. Baseline 12,000 pembacaan/detik yang terdokumentasi bertahan, dan kami tidak bisa menemukan batas sesungguhnya: pada 16,000/detik yang ditawarkan, lima dari delapan runner kami jenuh di sisi klien, jadi 12,762/detik adalah titik di mana armada kami mentok — bukan titik DynamoDB mentok. Pembacaan menjawab pada 2–4 ms p50 in-region.
Bagaimana plafon tumbuh di bawah beban berkelanjutan
AWS mendokumentasikan bahwa kapasitas on-demand tumbuh untuk mengakomodasi hingga dua kali puncak sebelumnya, dan bahwa melampaui dua kali puncak sebelumnya dalam 30 menit bisa memicu throttle. Kami menahan beban 8,000 penulisan/detik yang ditawarkan terhadap satu tabel selama 34 menit berturut- turut (empat gelombang 8 menit dengan jeda kurang dari satu menit di antaranya) dan mengamati plafonnya bergerak, menit demi menit:
| Gelombang | Mulai | Penulisan/s tercapai, menit demi menit |
|---|---|---|
| 1 | 06:06 UTC | 4,019 → 4,001 → 4,001 → 3,999 → 3,998 → 4,000 → 4,000 → 4,000 |
| 2 | 06:15 UTC | 5,046 → 5,000 → 4,996 → 4,990 → 4,991 → 4,998 → 4,992 → 4,993 |
| 3 | 06:24 UTC | 5,046 → 4,973 → 4,991 → 4,981 → 4,983 → 4,989 → 4,993 → 5,978 |
| 4 | 06:32 UTC | 7,006 → 6,991 → 6,979 → 6,996 → 6,991 → 6,988 → 7,002 → 6,990 |
Membaca garis waktunya:
- Plafon pertama itu lengket. Sepanjang 8 menit pertama, tabel bertahan di baseline ~4,000/detik-nya — over-demand yang berkelanjutan tidak menggesernya dalam jendela itu.
- Pertumbuhan datang dalam langkah ~1,000/detik, bukan ramp. Plafon melangkah ke ~5,000/detik sekitar menit ke-9, ~6,000/detik sekitar menit ke-26, dan ~7,000/detik semenit kemudian, lalu bertahan datar di 7,000/detik hingga akhir. Setiap langkah mendarat tiba-tiba antara satu menit dan menit berikutnya. Dua dari tiga langkah mendarat dekat batas gelombang kami, jadi jeda sub-menit itu mungkin berinteraksi dengan mekanisme pertumbuhannya — kami melaporkan timing-nya seperti yang teramati.
- Setengah jam permintaan berkelanjutan tidak menggandakan plafon. Setelah 34 menit pada 8,000/detik yang ditawarkan, tabel melayani 7,000/detik — 1.75× plafon awalnya, masih di bawah rate yang ditawarkan maupun penggandaan yang bersih. Request yang di-throttle turun dari gelombang ke gelombang (1.9M → 0.5M) seiring kapasitas tumbuh.
Jika trafik hari peluncuran Anda akan melampaui ~4,000 penulisan/detik pada tabel baru, panaskan lebih dulu: entah menjalankan beban sintetis sebelum acaranya, atau menyetel throughput on-demand maksimum tabel secara eksplisit dan biarkan AWS memprovisikannya. Panduan on-demand vs provisioned membahas kapan setiap mode unggul, dan auto scaling adalah pasangan mode provisioned dari apa yang barusan Anda saksikan terjadi otomatis di sini.
Dua angka yang mengejutkan kami
- Waktu create-ke-ACTIVE bervariasi 3×. Tabel on-demand baru mencapai
ACTIVEdalam 7.4 detik pada satu run dan 22 detik pada dua run lainnya, region sama, skema sama. Anggarkan untuk kasus lambat itu pada desain apa pun yang tabel-per-tenant atau tabel-per-test. - Seluruh benchmark berbiaya $0.97. 672,116 penulisan tertagih dan 1.08 juta pembacaan. Run pertumbuhan berkelanjutan 34 menit itu berbiaya $12.67 lebih. Mengukur layanannya sendiri lebih murah daripada satu keputusan kapasitas yang salah — dan Anda bisa menaksir harga beban kerja seperti ini di muka dengan kalkulator harga DynamoDB.
Cakupan dan metode, secara jujur
Semua di atas adalah satu tabel per fase, satu hari, satu region (us-east-1), item ~1 KB, key acak seragam. Batas per-partisi (3,000 read unit / 1,000 write unit per detik) berada di bawah perilaku level-tabel yang diukur di sini dan punya mode kegagalannya sendiri. Kuota level-akun dan batas layanan yang keras ada di referensi batas DynamoDB, diukur dengan cara yang sama. Dan jika Anda bekerja dengan DynamoDB setiap hari, DynoTable adalah klien desktop kami untuknya — dibuat oleh tim yang sama, dengan kebiasaan yang sama untuk memeriksa klaim terhadap layanan live sebelum mengulanginya.