Archive for the 'Introductory' Category
August 10, 2020
by
Michael KlishinOver time, we have seen the number of Kubernetes-related queries on our community
mailing list
and Slack channels soar. In this post we’d like to explain the basics
of a DIY deployment of RabbitMQ on Kubernetes: what Kubernetes resources will be necessary, how to make sure
RabbitMQ nodes use durable storage, how to approach configuration of sensitive values, and so on.
April 16, 2012
by
Simon MacMullenSo today I would like to talk about some aspects of RabbitMQ’s
performance. There are a huge number of variables that feed into
the overall level of performance you can get from a RabbitMQ
server, and today we’re going to try tweaking some of them and
seeing what we can see.
September 24, 2011
by
Matthew SackmanOne of the problems we face at the RabbitMQ HQ is that whilst we may
know lots about how the broker works, we don’t tend to have a large
pool of experience of designing applications that use RabbitMQ and
which need to work reliably, unattended, for long periods of time. We
spend a lot of time answering questions on the mailing list, and we do
consultancy work here and there, but in some cases it’s as a result of
being contacted by users building applications that we’re really made
to think about long-term behaviour of RabbitMQ. Recently, we’ve been
prompted to think long and hard about the basic performance of queues,
and this has lead to some realisations about provisioning Rabbits.
January 20, 2011
by
Matthew SackmanFrom time to time, on
our mailing
list and elsewhere, the idea comes up of using a
different backing store within RabbitMQ. The backing store is
the bit that’s responsible for writing messages to disk (a message can
be written to disk for a number of reasons) and it’s a fairly frequent
suggestion to see what RabbitMQ would look like if its own backing
store was replaced with another storage system.
Such a change would permit functionality that is not currently
possible, for example out-of-band queue browsing, or distributed
storage, but there is a fundamental difference in the nature of data
storage and access patterns between a message broker such as RabbitMQ
and a generic database. Indeed RabbitMQ deliberately does not store
messages in such a database.
January 12, 2011
by
Jakub StastnyIn the past year development of the AMQP gem was practicaly stagnating, as its original author Aman Gupta (@tmm1) was busy. A lot of bugs stayed unresolved, the code was getting old and out-dated and no new features or documentation were made.
At this point I started to talk with the RabbitMQ guys about possible collaboration on this. Actually originally I contacted VMware when I saw Ezra Zygmuntowicz looking for people to his cloud team, but when I found that VMware recently acquired the RabbitMQ project in London, I got interested. I signed the contract, switched from script/console
to Wireshark and the RabbitMQ Tracer and since November I’ve been happily hacking on the AMQP and AMQ-Protocol gems.
November 17, 2010
by
John DeTrevilleRabbitMQ needs more and better documentation. (And who doesn’t?) In particular, we need more and better introductory material that introduces the reader to various basic concepts, explains why they’re important, and motivates him or her to keep reading and learn more about RabbitMQ. Here’s a cut at Chapter 1 of that introduction. Your comments are welcome, and Chapters 2 and 3 will follow soon.
(You probably already know all of this, but a surprising number of people don’t. This introduction is for them.)