我在Amazon EC2上有2個實例。一個是作爲網頁緩存服務器的t2.micro
機器,另一個是性能測試工具。EC2機器或網絡是否有任何限制?
當我開始測試,TPS(每秒事務數)約爲3000。但幾分鐘後TPS已經下降到300
起初我以爲CPU貸方餘額耗盡,但它足以處理請求。在測試期間,Web緩存的最大傳出流量爲500Mbit/s,CPU使用率爲60%,可用內存綽綽有餘。
我找不到TPS減少的原因。 EC2機器或網絡有沒有限制?
我在Amazon EC2上有2個實例。一個是作爲網頁緩存服務器的t2.micro
機器,另一個是性能測試工具。EC2機器或網絡是否有任何限制?
當我開始測試,TPS(每秒事務數)約爲3000。但幾分鐘後TPS已經下降到300
起初我以爲CPU貸方餘額耗盡,但它足以處理請求。在測試期間,Web緩存的最大傳出流量爲500Mbit/s,CPU使用率爲60%,可用內存綽綽有餘。
我找不到TPS減少的原因。 EC2機器或網絡有沒有限制?
有幾個因素可能會限制您的流程。在T2實例
正如你提到,對爆破CPU T2 instances使用信用
CPU學分。它們是非常強大的機器,但每個實例僅限於一定數量的CPU。 t2.micro
實例給出CPU的10%,這意味着它們實際上只有10%的時間(以低毫秒分辨率)獲得100%的CPU。
實例以CPU信用開始以獲得快速啓動,並且在CPU使用速度快於獲得信用時消耗這些信用。但是,您說信貸餘額已足夠,所以這似乎不是原因。
網絡帶寬
每個Amazon EC2實例可以使用的網絡帶寬一定的吞吐量。更小的實例具有「低」帶寬,更大的實例具有更多。有帶寬的大小沒有官方的說法,但是這是從Serverfault一個有趣的參考:Bandwidth limits for Amazon EC2
磁盤IOPS
如果應用程序使用的每個交易接盤,並且您的實例使用通用(SSD)實例類型,那麼您的磁盤可能已經消耗了所有可用的突發信用。如果您的磁盤很小,這可能意味着它運行速度很慢(速度爲每GB 3 IOPS,因此20 GB磁盤將以60 IOPS運行)。檢查Amazon CloudWatch VolumeQueueLength
metric以查看IO是否過度排隊。
別的東西
放緩也可能是由於你的應用程序或高速緩存系統(例如沒有空餘的內存用於存儲數據)。
我測試過t2.micro實例有多少流量限額。看來t2.micro在10分鐘內有15-20G的外出流量補貼。在交通補貼耗盡後,將實施50M bps。 – user3413814
奇怪的是,網絡帶寬有一個可變的限制 - 這可能是你的CPU限制? –
我測試過機器是新創建的每個測試。所有的測試都在10分鐘內完成。我認爲CPU的存款餘額就夠了。其他資源如CPU使用率,可用內存也足夠了。只有網絡帶寬受到未知原因的影響。 – user3413814
你有沒有發現爲什麼交易下降? –