Hlavní navigace

Názor k článku RabbitMQ: jedna z nejúspěšnějších implementací brokera od Kenny - Kolega dělal před pár lety srovnání než jsme...

  • Článek je starý, nové názory již nelze přidávat.
  • 21. 12. 2018 18:34

    Kenny (neregistrovaný)

    Kolega dělal před pár lety srovnání než jsme Rabbita nasazovali. Bylo to na verzi RabbitMQ 3.4.4 s Pythonem 2.7.6 a Twisted 15.0. Testoval na Ubuntu 14.04 na HW Intel i5-3320M, 8GB RAM s SSD diskem. Zde jsou poznámky z dokumentu:

    Výkon
    cca 10000 zápisů persistentích několika-bytových zpráv a 10000 potvrzovaných čtení za vteřinu
    limitem je Twisted, kde reactor běží v jednom vlákně, např. při posílání 300000 zpráv ve smyčce se 15 vteřin "skoro nic neděje" a až pak se začnou posílat, potom, co už reactor není vytížen řazením zpráv pro odeslání (při řazení je tam ale yield na možnost vykonat v reaktoru další věci)

    Pika blocking connection
    jednak je pomalé při použití jednoho vlákna (300 odeslaných zpráv za vteřinu)
    za druhé při zátěžových testech docházelo k stack overflow, protože se při odesílání acku volá něco jako process_messages()
    nebrat

    Ale je to 3 roky starý test a od té doby se lecos mohlo změnit. V produkci (call centra s zátěží do 100 souběžných hovorů, cca. 10 eventů za vteřinu) takových hodnot zpráv za sekundu zdaleka nedosahujeme, takže testování zátěže s aktuálními verzemi bohužel nemám k dispozici.

    Oproti implementaci s multicastem pro Váš specifický use-case bude Rabbit určitě pomalejší už jen z logiky věci, že se jedná o univerzální řešení frontování, které navíc komunikuje unicastově.