Workload Prioritization Performance and an Example

How do we do this, how does one just
configure workload prioritization, so first of all, does it work, so yes it does minimize
as you can see, it’s the same experiment form the start but with workload prioritization on
so what you can see again at OLTP enjoys low latencies and when
OLAP kicks in, the latency increased a little but it is much lower in relation to this OLAP
what you’ll see you later is that OLAP still enjoys very high throughput, which OLTP doesn’t need
so it will keep stable throughput throughout this test, so here again this is
the system point of view of this thing, we just gave a lot of shares to OLTP, so it gets cleared
as soon as possible and very low amount of shares to OLAP, so only when there is no conflict
it will get processed or when the ratio will be a flipped, which will happen not very often
because OLTP doesn’t need the whole processing power, so how do you configure such a setup
it involves three different steps, first you recognize all of the users that
generate the same type of workload then you just attached to them single role, role is
a part of authentication system and there are other ways to do it but this is the easiest so you
just attach a role to them that they all inherit, then you create, what we call – a service level
this is the actual share amount that you want this workload to get, you give it a name and shares
then you attach this service level to the role, you can attach it to multiple roles if
you have several groups of users that generate the same workload
but this is the simplest and easiest scenario
so just to put it in commands, this is all you have to do to get to workload prioritization going
the first two CQL queries are not even part of our workload prioritization API, it’s just part
of our authentication API which is well documented, so you can go ahead and see it and all you
need to do as far as workload prioritization is concerned
is to create the service level give it the shares
and attach it to the right role, so this is how we get them to coexist, this is the set-up
used to show the earlier graph, which was latencies
and this is the same experiment
but from throughput perspective, so you can see that OLAP always gets all of the throughput that is left
the server has to offer and relatively constant throughput that OLTP has, stays pretty constant during the experiment
so this is how we do it, so this is a good time to just say that we have one constrain
it is a derivative of our system requirements to be a low latency system as a whole
so the end result of this is that we currently only can handle 8 different workloads, it doesn’t
mean 8 different users but you can attach the same workload to a lot of users but you can
only have 8 different workloads, so just to see that this solution scales, we’ll see an
example with three workloads, they’re just assigned an increasing amount of shares
and here this is the latency graph so you can see, the more shares you have the less
latency you’ll have, so load3 which has the most amount of shares
will get very low latencies relative to the other workloads
and of course the graph of throughput will be reverse,
so the more shares you have the more throughput you can get out of the system
if you want to, and this is what we see here
To summarize the goal of this whole feature
is to actually minimise inter-workload impact without breaking the bank, which means to decrease
your data center footprint and schedulers are in the heart of the solution and shares
are really all there is to it.