爲什麼boto dynamodb2 get_item速度不一致，看起來經常很糟糕？

爲什麼我的dynamodb通過boto請求：get_item如此慢而且太頻繁很慢？ AWS控制檯報告我的延遲時間高達12.5ms。我的要求都沒有接近那麼低。爲什麼boto dynamodb2 get_item速度不一致，看起來經常很糟糕？

的Python 2.7.5 AWS區美西1 博託2.31.1 dynamodb表大小180K〜記錄

代碼：

from boto.dynamodb2.fields import HashKey 
from boto.dynamodb2.table import Table 
from boto.dynamodb2.types import STRING 
import boto.dynamodb2 
import time 

REGION = "us-west-1" 
AWS_KEY = "xxxxx" 
AWS_SECRET = "xxxxx" 

start = time.time() 
peeps = ("cefbdadf518f44da8a68e35b2321bb1f", "7e3a691df6134a4f83d381a5507cbb18") 
connection = boto.dynamodb2.connect_to_region(REGION, aws_access_key_id=AWS_KEY, aws_secret_access_key=AWS_SECRET) 
users = Table("users-test", schema=[HashKey("id", data_type=STRING)], connection=connection) 
for peep in peeps: 
    user = users.get_item(consistent=True, id=peep) 
    print time.time() - start

結果：

(botot)➜ ~ python test2.py 
0.056941986084 
0.0681240558624 
(botot)➜ ~ python test2.py 
1.05709600449 
1.06937909126 
(botot)➜ ~ python test2.py 
0.048614025116 
0.0575139522552 
(botot)➜ ~ python test2.py 
0.0553398132324 
0.064425945282 
(botot)➜ ~ python test2.py 
3.05251288414 
3.06584000587 
(botot)➜ ~ python test2.py 
0.0579640865326 
0.0699849128723 
(botot)➜ ~ python test2.py 
0.0530469417572 
0.0628390312195 
(botot)➜ ~ python test2.py 
1.05059504509 
1.05963993073 
(botot)➜ ~ python test2.py 
1.05139684677 
1.0603158474

更新2014-07-11 08:03 PST 實際用例正在爲每個Web請求查找用戶。正如@gamaat所說，DynamoDB的成本是在第一次查找時發生的，因爲這是在HTTPS連接建立時進行的。所以看起來如果我可以在請求之間存儲DynamoDB連接並重用它，事情會更快。所以我用werkzeug.contrib.cache.FileSystemCache來存儲連接，但它似乎永遠不會存儲連接以進行檢索。其他值得到良好存儲，只是沒有這個連接對象。有任何想法嗎？如果這不是存儲請求之間連接的好方法，那麼是什麼？

更新2014年7月11日15:30 PST 由於我使用的是主管和uwsgi來管理我的瓶的應用程序，似乎這個問題實際上是我如何共享請求之間的連接對象爲我的瓶應用程序。

來源

2014-07-11 vovel

您的測試包括創建到服務的HTTPS連接所需的時間，這實際上是一次性成本。另外，爲了獲得更準確的平均延遲的想法，我會嘗試檢索兩個以上的項目。嘗試做1000或更多，並平均出來。 – garnaat

的解決方案，似乎是產生更好的響應時間的問題（以前的平均響應時間爲〜500毫秒，之後是〜50毫秒）是做兩件事情：

1）把寶途DynamoDB連接對象在default_settings.py中，以便每次載入應用程序時將其加載到app.config [「DYNDB_CONN」]中一次;和

2）配置uwsgi有一個便宜的num_proccesses - 1值，而便宜的初始值爲num_proccesses - 1。這告訴uwsgi總是有num_processes - 1個uwsgi進程始終運行，並啓動選項如果負載需要，還有一個過程。

我這樣做是爲了儘量減少重新啓動的uwsgi進程的數量，因此創建一個新的Boto DynamoDB連接對象（引發HTTP連接設置成本）。

來源

2014-07-14 19:21:47 vovel

其實，我使用t1.micro作爲我的NAT，這是真正的，真正的瓶頸。 – vovel

爲什麼boto dynamodb2 get_item速度不一致，看起來經常很糟糕？

回答

相關問題