RabbitMQ Best Practice | Webinar with CloudAMQP

Some applications require really high throughput while other applications are publishing batch jobs that can be delayed for a while. The goal when designing your system should be to maximise combinations of performance and availability that make sense for your specific application.
Bad architecture design decisions or bugs client side, can damage your broker or affect your throughput. Your publisher might be halted or the server might crash due to high memory usage. This webinar focuses on best practice for RabbitMQ. Dos and don'ts mixed with best practice for two different usage categories; high availability and high performance (high throughput).
Carl Hörberg has been working with RabbitMQ since version 2.6. He launched CloudAMQP(RabbitMQ as a Service) 2012, which today is the industry-leading hosted service for RabbitMQ. Carl and his team know how to configure for optimal performance and how to get the most stable cluster. In this webinar, Carl shares his RabbitMQ knowledge.
What will you learn?
* RabbitMQ best practice for High Performance
* RabbitMQ best practice for High Availability
* Common RabbitMQ mistakes
WEBINAR LIVE DATE: Thursday 25 January 2018 | 1700 CET / 1600 GMT / 1100 EST / 0800 PST
Deck: www.slideshare.net/secret/ndM...
-----------------------
SPEAKER CONTACT DETAILS
CARL HÖRBERG - Carl Hörberg has been working with RabbitMQ since version 2.6. He launched CloudAMQP 2012, which today is the industry-leading hosted service for RabbitMQ. Carl and his team have probably seen way more configuration mistakes than anybody else. He knows how to configure for optimal performance and how to get the most stable cluster.
CloudAMQP is RabbitMQ as a Service - Managing the largest fleet of RabbitMQ clusters in the world.
Twitter: / carlhoerberg
CloudAMQP: www.cloudamqp.com
-----------------------
COMPANY CONTACT DETAILS
ERLANG SOLUTIONS
- Website: www.erlang-solutions.com
- Twitter: / erlangsolutions
- LinkedIn: / erlan. .
- GitHub: github.com/esl

[@yoloswaggins2161]

I like the no-nonsense approach.

[@chakala2149]

Thank you AMQPCloud folks for sharing this helpful knowledge.

[@hamiltonvera188]

Amazing, solved many of our problems. Thanks a lot, very good material

[@Textras]

Great Tips! Tnx

[@prabhakarpalanivel6472]

By TCP Packages, i think the presenter is referring to TCP packets

[@motleypixel]

XFS is best file system...how would you rate using NFS 4 (NAS)?

[@motleypixel]

I "think" using SNAT with the load balancer will eliminate any asymmetric routing issues.

[@Textras]

Also very curious behind decisions to base Mongoose.IM (by Erlang) on XMPP, not RMQ?

[@ucheozoemena2499]

Great vid! Question: is it good practice to have a queue for every user that gets added to your database? This is in the context of a chat app. I'm trying to configure a rabbitmq broker as the event source for a lambda in aws, but it requires providing the name of the queue at the moment the event source is created, which wouldn't be possible for users that haven't yet joined. How would you handle the possibility of dynamically generated queues as the event source for the lambda? Perhaps it was a bad design choice to have a queue for each user?

[@coordinates_]

Bro, did you find a solution for this