Yeni bir DynamoDB tablosu throttling'e girmeden önce saniyede kaç yazma kaldırır?

AWS, yepyeni bir on-demand tablonun kutudan çıktığı gibi "up to 4,000 write request units per second" sunduğunu belgeliyor. Gerçekte ne olduğu konusunda herkesin hâlâ alıntıladığı çalışma — Capital One'ın da ScyllaDB'nin de bağlantı verdiği çalışma — bunu 2019'da, warm throughput'tan önce, yapılandırılabilir maksimumlardan önce, bugünkü ölçekleme kuralları var olmadan önce ölçtü. Görebildiğimiz kadarıyla o zamandan beri kimse bir ölçüm yayımlamadı.

Biz de bir tane çalıştırdık. 2026-08-27'de, us-east-1'de dakikalar önce oluşturulmuş bir tabloya karşı, sunulan yazma yükü saniyede 1.000 istekten 8.000 isteğe yükseltildi:

Belgelenen taban değer geçerli ve biraz da temkinli: servis, 4.000/s'ye kadar her şeyi tek bir ret olmadan kabul etti, sonra ne kadar zorlarsak zorlayalım saniyede 4.130 ±2 yazmada sabitlendi. Üç pencere, üç sunulan hız, %0.05'lik bir sapmayla aynı tavan. Okumalar hiç kısıtlanmadı — tohumlanmış bir tabloyu saniyede 12.700 nihai tutarlı okumanın ötesine sürdük ve bunun üzerindeki eksik, DynamoDB değil kendi istemcimizdi.

Tek tablo, tek gün, tek bölge, tekdüze rastgele anahtarlı ~1 KB'lık öğeler — ortada hot partition yok. Buradaki her sayının dürüst künyesi bu kapsamdır. Yazının geri kalanı bunu nasıl ölçtüğümüz — benchmark'ın çalışmadan önce üç kez başarısız olduğu kısım dahil; ve başarısızlıkların hiçbiri DynamoDB'nin suçu değildi.

Kısıtlama bir 400 ve ilk olarak yanlış şüpheliyi işaret ediyor

Tavana çarpıldığında aldığın hata dikkatle okumaya değer:

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.html

Üçü de ölçülmüş üç gözlem:

• Bu bir HTTP 400, 5xx değil. Retry politikanın ve panolarının bunu bilmesi gerekir. Yalnızca 5xx'i yeniden deneyen bir istemci bunları yere düşürür; yalnızca 5xx'te alarm veren bir izleme, yazmalarının üçte biri geri teperken servisi yeşil gösterir.
• İlk kısıtlama, taban değerin üzerindeki her pencerenin başlangıcından 0.9–3.8 saniye sonra geldi — servis, tavan devreye girmeden önce sana kısa bir tolerans patlaması verir ve sunulan hız ne kadar yüksekse o kadar erken ısırır.
• Hot key ipucu bir varsayılan, teşhis değil. Anahtarlarımız tekdüze rastgele UUID'lerdi; hot key yoktu. Küçük ölçekte bu mesajın ilk şüphelisi düpedüz tablo düzeyindeki tavandır.

Gecikme bunların hepsine kayıtsız kaldı: p50 yazma gecikmesi, kısıtlanmış olsun ya da olmasın her pencerede bölge içinde 4–5 ms'ydi. Reddetmek servis için ucuzdur — yavaşlamaz, sadece hayır der.

Bunu bir dizüstünden ölçemezsin

İlk enstrümanımız bariz olandı: Madrid'deki bir dizüstünde bir Node betiği. Saniyede 1.000 yazmayı temiz bir tempoyla sürdü ve 2.000'de çöktü — DynamoDB geri ittiği için değil, ~100 ms'lik Atlantik gidiş-dönüşü saniyede 2.000 uçuştaki isteğin yüzlerce eşzamanlı soket gerektirmesi anlamına geldiği ve event loop boğulduğu için. Servis bir kez bile kısıtlamadı. Kendi Wi-Fi'mizi benchmark ediyorduk.

İkinci deneme, koşucuyu tek bir Lambda fonksiyonu olarak hedefle aynı bölgeye taşıdı. Bölge içi gidiş-dönüş ~5 ms ve 3 GB'lık tek bir fonksiyon, 10 ms p50 ile saniyede 2.000 isteği temiz bir tempoyla sürdü. Ondan sonrası, CPU dibe vurmuş halde 1.100/s civarında düzleşti: istek imzalama ve yanıt işleme tek iş parçacıklı JavaScript'tir ve tek bir koşucu saniyede 4.000 isteği düpedüz imzalayamaz. Ayrılan bellek: 3 GB. Kullanılan bellek: 253 MB. Darboğaz asla RAM değildi — bir Lambda'nın CPU payı bellek ayarıyla ölçeklenir ve biz depolama değil, hesaplama satın alıyorduk.

Böylece nihai enstrüman, her biri toplam sunulan hızın sekizde birini süren ve pencereleri hizalansın diye hepsi ortak bir duvar saati T0'ına karşı başlatılan sekiz Lambda'lık bir filo oldu. Her biri rahat 1.000/s'de sekiz koşucu, bize pay bırakarak 8.000/s'lik sunulan yük verdi ve toplam, sayılmış isteklerin toplamıdır — hiçbir yerde ekstrapolasyon yok.

Biri işe yaramadan önce üç koşu öldü ve DynamoDB her seferinde masumdu

Filonun ilk koşusu, bir koşucunun T0'dan 882 saniye sonra başladığını bildirmesiyle bitti — yirmi saniyelik bir randevuya on beş dakika geç. İkinci koşu bir okuma zaman aşımıyla öldü. Retry'ları kapalı olan üçüncüsü, sekiz koşucunun hepsinde birden gürültüyle başarısız oldu. Bu sırada CloudWatch, her bir Lambda'nın dört dakikalık ölçümünü temizce, zamanında ve hatasız bitirdiğini gösteriyordu.

Suçlu, dizüstü ile Lambda arasındaki bağlantıydı. Senkron bir çağrı, koşunun tamamı boyunca tek bir HTTPS bağlantısını tamamen sessiz halde açık tutar — ve ev tipi bir yönlendirici, sessiz bağlantıları birkaç dakika sonra sessizce öldürür. Ölü bir soket gören CLI, olabilecek en kötü şeyi yaptı: sessizce yeniden denedi ve T0'ını çoktan kaçırmış bir ölçüm Lambda'sını yeniden çalıştırdı. Görünmez biçimde iki kez çalışabilen bir benchmark koşum takımı, koşum takımı değildir; AWS faturası olan bir rastgele sayı üretecidir.

Sonunda işe yarayan biçim, artık uzun süren her uzak ölçüm için kullanacağımız üç kurala sahip:

• Ateşle ve unut, sonuçlar bant dışı. Koşucular asenkron çağrılır (bağlantı milisaniyeler içinde kapanır) ve sonuçlarını küçük bir DynamoDB tablosuna öğe olarak yazar; sürücü sekiz sonuç satırı için yoklama yapar. Hiçbir bağlantı bir istekten uzun yaşamaz.
• Retry'lar her yerde kapalı. Ölçüm istemcisi istek başına tek denemeyle çalışır — bir retry, saymak için var olduğumuz kısıtlamaları sessizce yutardı — ve çağrı yolunda da retry'lar kapalıdır, böylece hiçbir koşucu asla iki kez çalışamaz.
• Takılma yerine bir bekçi. Her koşucu, programını bir son teslim anına karşı yarıştırır; bir şey sıkışırsa, sessizce zaman aşımına uğramak yerine kısmi sayımları artı tam olarak nerede takıldığının bir anlık görüntüsünü döndürür. Kendini açıklayan başarısız bir koşu bir okumaya mal olur; takılan bir koşu bir akşama.

Ayrıca her istek 8 saniyelik bir zaman aşımı taşır. Takılan koşu, zaman aşımı olmayan tek bir uçuştaki isteğin son boşaltma adımını sonsuza dek sıkıştırması yüzünden takıldı. ~4 milyon istek başına tek bir sınırsız bekleme yetti.

Okumalar ne yaptı

Okuma aşaması, 1.000 öğeyle tohumlanmış ikinci bir taze tabloya karşı, nihai tutarlı GetItem çağrılarıyla çalıştı (her biri ~1 KB, 0.5 okuma birimi):

Hiç kısıtlama olmadı, bir kez bile. Belgelenen saniyede 12.000 okumalık taban değer geçerli ve sınırını bulamadık: sunulan 16.000/s'de sekiz koşucumuzun beşi kendi istemci tarafı doygunluğuna çarptı, yani 12.762/s rakamı DynamoDB'nin değil, bizim filomuzun tavan yaptığı yer. Bunu bir servis sınırıymış gibi süslemek yerine açıkça söylüyoruz. Bölge içi okumalar 2–4 ms p50'de çalıştı.

Saklamaya değer iki küçük sayı: taze bir on-demand tablo, benchmark koşusunda CreateTable'dan ACTIVE'e 22 saniyede, daha önceki bir yoklamada 7.4 saniyede geçti — en iyi duruma değil, bu değişkenliğe bütçe ayır. Ve 672.116 faturalanan yazma ile 1.08 milyon okumadan oluşan benchmark'ın tamamı $0.97'ye mal oldu. Enstrüman yeniden kullanılabilir; deney bir kahve.

Yarım saatlik baskı tavanı ikiye katlamıyor

AWS'nin büyüme kuralı, on-demand kapasitenin önceki zirvenin iki katına kadarını karşıladığını söyler. Bunun gerçekleşmesini görmek istedik; bu yüzden tavan koşusundan sonra bir tabloyu 34 kesintisiz dakika boyunca saniyede 8.000 yazmalık sunulan yükte tuttuk ve ulaşılan hızı 10 saniyelik kovalara böldük. Ortaya çıkan biçim:

Büyüme bir rampa halinde değil, ani ~1.000/s'lik basamaklarla gelir — bir dakika bir hızda düz, sonraki dakika bir sonrakinde düz. İlk tavan, tam 8 dakikalık kesintisiz aşırı talep boyunca yapışkandır. Ve 34 dakika sonra tablo 7.000/s sundu: başladığı yerin 1.75 katı, yine de sunulan 8.000'in ve temiz bir ikiye katlanmanın gerisinde. Lansmanın yeni bir tabloda ~4.000 yazma/s'den fazlasına ihtiyaç duyuyorsa, tabloyu önceden ısıt ya da maksimum on-demand verimliliğini açıkça ayarla — büyüme mekanizması gerçek, ama ne anlık ne de senin takvimine cömert. Davranış ayrıca istikrarlı: 2019 çalışmasında 9.000/sn yük altındaki tablo, test bittiğinde yaklaşık 7.000/sn’ye ulaşmıştı — bizimkinin yedi yıl sonra ulaştığı platonun aynısı. O koşu $12.67'ye mal oldu; bütün gün yaptığımız en pahalı şey.

Bir bulut servisini kendin ölçersen neler aktarılır

• Yük üretecini hedefle aynı bölgeye koy. Yoksa servisi değil, kendi rotanı ölçersin.
• Tek bir Node süreci, bellekten bağımsız olarak saniyede 2.000 imzalı istek civarında tavan yapar; yükü koşuculara parçala ve sayılmış sonuçları topla.
• Ölçüm yolunda, her katmanda retry'ları kapat. Retry'lar, tam da bir benchmark'ın görmek için var olduğu şeyi gizlemek için vardır.
• Uzun bir koşu boyunca asla sessiz bir bağlantı tutma. Asenkron çağır, sonuçları bant dışı teslim et, yoklama yap.
• Her isteğe bir zaman aşımı, her koşucuya da takılma durumunun anlık görüntüsüyle kısmi veri döndüren bir bekçi ver.
• Koşucu başına sert bir işlem tavanı koy ki bir tempolama hatası faturayı şişirmek yerine iptal olsun; ve koşunun oluşturduğu her şeyi — tabloları, rolleri, fonksiyonları, logları — bir finally içinde yık.

Bunun beslediği başvuru sayfaları

Veri kümesinin tamamı — her pencere, her koşucu, gecikme yüzdelikleri, hataların birebir metinleri — artık daha önce yayımladığımız öğe boyutu ve sayfa sınırı yoklamalarının yanında DynamoDB sınırları başvurumuzdaki ölçülmüş tabloları destekliyor. DynamoDB'ye karşı her gün çalışıyorsan, DynoTable bunun için masaüstü istemcimizdir — aynı ekip, iddiaları tekrarlamadan önce canlı servise karşı denetleme alışkanlığı aynı.