Re: Designing for maximum Artemis performance
Although some concept of either AZ affinity or preference for active
masters to live on different physical hosts/AZs could be helpful and might
be worth considering (Kafka has the concept of rack awareness to avoid
putting all copies of any particular message on the same hardware, which
can be used in AWS to avoid having them on the same AZ), I wonder if the
underlying problem is the design decision to colocate two Artemis processes
on the same host.
If each slave was on a separate EC2 instance, then the slave would be fully
capable of acting as a master when necessary (including having sufficient
network bandwidth). Your current setup results in a slave that can only
operate in a degraded fashion, which is not the ideal scenario, especially
without any feature to prefer offloading one of the masters to the new host
when it comes up. Obviously the approach I'm describing will increase your
EC2 costs, but maybe that's the right tradeoff given the current feature
set of Artemis.
On Wed, Oct 3, 2018, 2:40 AM schalmers <
> Hi Mike,
> I'm not looking at getting improved performance by having multiple slaves.
> The use case I have is master-multiple backups as per
> Our architecture is complex and we're using QPID dispatch routers at other
> points within that. What I need to do is guarantee, for example, 600MB/s
> throughput. If the simplest way to do that is a single server with three
> masters on it, then I'll do that, if that guarantees 600MB/s. I doubt it
> will work though.
> If we need to spread the load and have 3x 200MB/s throughput across 3
> servers then I'll do that. But I'll have multiple producers and consumers
> connecting to those 3 instances at any point in time. By doing so, I'm
> assuming that for the most part, Artemis can achieve 600MB/s across the 3
> servers. If one of those servers / AZ dies for a short period of time, I'm
> comfortable with having 2 servers running - with 1 server having 2 masters
> and 1 server with 1 master - and only having ~400MB/s performance. But the
> end goal is always trying to run @ 600MB/s across 3 servers split across 3
> AZ. That way the applications connecting to Artemis can survive a server/AZ
> failure, with a diminished level of performance (i.e. the ~400MB/s for a
> small window of time). The only way I see to achieve that is live-backup
> groups and running failback. However, it seems failback is not supported in
> that scenario, hence my questions from the original post.
> I don't understand what you mean by a cluster with multiple masters? Do you
> mean a live-live-live cluster?
> Sent from: