我們的團隊正在Spike Sprint中進行ActiveMQ或RabbitMQ之間的選擇。我們做了2個小生產者/消費者尖峯,發送一個包含16個字符串,時間戳和2個整數的對象消息。我們的開發機器上的尖峯狀況良好(消息消耗良好)。RabbitMQ消息消費者不再使用消息
然後來到板凳。我們首先注意到,在我們的機器上,當我們發送大量消息時,消費者有時會掛斷。它在那裏,但消息堆積在隊列中。
當我們去在板凳上。平臺:
集羣- 2 RabbitMQ的機器4芯/ 3.2Ghz的,4GB RAM,負載由VIP在RabbitMQ的機器上運行
- 至6之一的消費者平衡,將消息保存在一個mysql數據庫中(DB的機器類型相同)
- 12個生產者運行在12臺AS機器(tomcat)上,運行在另一臺機器上的jmeter攻擊。在產生相同負載的RabbitMQ消息的servlet上,每秒的負載約爲600到700個http請求。
我們注意到,有時,消費者掛(當然,他們不會被阻止,但他們不消費了消息)。我們可以看到,因爲每個消費者在數據庫中節省大約100 msg /秒,所以當一個消費者停止消費時,數據庫中每秒鐘節省的總體消息以相同的比率下降(如果讓3個消費者停下來,我們將下降約600 msg /秒至300毫秒/秒)。
在此期間,生產者沒問題,仍然以jmeter的速度生產(約600 msg/sec)。消息仍在隊列中,消費者仍然是「活着」的。
我們首先加載所有的servlet,然後逐個啓動所有消費者,檢查連接是否正常,然後運行jmeter。
我們正在發送消息給一個直接交換。所有消費者都在聽一個與交易所有關的持續隊列。
這點對我們的選擇很重要。你有沒有看過這個與rabbitmq,你知道發生了什麼?
謝謝你的回答。
這可能更適合於serverfault。 – danben 2010-07-19 20:25:37
謝謝,我會將它張貼在serverfault中。 – 2010-07-19 20:37:30
奇怪的是,沒有提到版本。例如,Ubuntu和Debian傾向於打包舊版本的東西,但是當這些東西是一個處於積極開發階段的關鍵工具時,比如RabbitMQm,最好運行更新的版本。 – 2011-06-11 06:26:50