%% Last Updated: - [[2021-02-11]] - [[2020-12-08]] Related: - [[k6 (Company)]] %% Author: [[Leandro Melendez]] URL: https://www.youtube.com/watch?v=mtDjsJDNDPA&feature=youtu.be&ab_channel=Se%C3%B1orPerformo (draft) %%This is a video that k6 paid Leandro for, the first part of a two-part series.%% ## Transcript Hello, and welcome to the K6 series of videos. Here we are going to explore the K6 tool, as well as relevant topics related to it and learn how to implement them in the tool itself. My name is Leandro, better known in the internets as Señor Performo, and for the next two episodes, I will be your guide through this module's topic. SLOs and thresholds. The topic will be divided in two parts. On this first part, we will go over the definitions and descriptions of the key elements of today's topic. We will talk about what are SLOs and Thresholds. And on the second episode, we will get a walkthrough on how to apply that knowledge on our dear K6 tool. So, to not to waste more time, why don't we jump on the topic. Let's start talking about de definitions for these key elements. We will start with the question, what is an SLO? And given that the term is an acronym, what does it stand for? It is easier to start defining the acronym. SLO stands for Service Level Objective. In other terms, a goal for a measurement in the specified service. Do not confuse SLO with an SLA. They may sound very similar and are even very frequently confused with each other, but they are not the same, instead, they are related. Please dont use them interchangeably. An SLO is a part of an SLA. In other words an SLA contains multiple SLOs. You may be wondering now, what is the difference among them? Well, here... I must admit, I also confused them for a long time. So let's clarify this. Officially, SLA is an acronym that stands for Service Leve AGREEMENT. Here as you can see, the difference is that there is an agreement instead of an objective. Duh. But. If you want to think it in another way, an agreement is somewhat like a contract or a compromise that is established. This contract is done generally with a customer. In the SLA or contract it contains SLOs. Those are many objectives that need to be reached to fulfill that agreement. Generally, not reaching those objectives for the agreements, imposes some sorts of penalizations if the objectives are not fulfilled. To move on we will leave it here with the SLAs. They are contracts agreeing to fulfill a list of objectives. Now, let's go over the SLOs: As we mentioned earlier, SLO stands for Service level OBJECTIVE. Think of the objectives as goals. These goals generally are measured over specific metrics or INDICATORS. These indicators are as well part of the service level realm. As inside of an SLO we have many indicators, known as SLIs. Now back to SLOs, the OBJECTIVES for those indicators can be defined in two ways: specific, or in ranges. On the specifics, a fixed number is assigned as the objective, stating that the metric should be of an X value. The next one, the range, generally states that the objective for the metric is to be smaller than X, or not pass it. A third type of objective would be for the indicator to stay in between two values. To be more than X, but not greater than Y. A few examples of these objectives applied to performance could be the following: For a fixed one, think of an elastic environment, the objective could be that the assigned RAM memory is always 16GB for our app server. In other words, Assigned RAM = 16GB Now. For the type that we mentioned as "smaller than", the objective could be for the CPU usage to not to pass over 80% of utilization at any time. Or CPU<80% An example now, for the "larger than", could be uptime. The objective could be for your service to be available at least 95% of the time. Or Uptime>95%. And last, an example for the "range" objective could be on the temperature of the machine or the CPU. The objective would be for it to be hotter than 5 degrees Celsius but not more than 40. Or 5<Temperature<40 THRESHOLD is another word to refer to these ranges. They are the gates in which a result must stay in. The maximums and if needed minimums for every measurement. As you could notice, the SLOs or thresholds that I showed here are very specific. A number for the CPU, maximum seconds to respond for a specific transaction, etc. And that is a key element for them, to have specific definitions, nothing vague here please. Bieng vague and unclear is often the reason why they are not very loved and hard to work with. I have experienced that vagueness often. Especially in response times where their objectives are stated so wide open that it is hard to keep achieve them. A real life example that I have lived, and that sadly I have requested myself at times, are vague objectives set for server response times. Who has not heard the objective "Every response must be under 3 seconds"? Well excuse me, but not EVERYTHING can respond in under 3 seconds. Actually not everything SHOULD respond that fast! And that is a small example why you must be careful with those objectives. Be precise and thoughtful with them! Now, I want to go back to the last ones, the Service level indicators, or SLIs. Since there are some confusions amongst those too. The SLIs are simply the current readings on your metrics. I think those one are the simplest ones. Just look at the measurement and report it. That is your SLI. Plain and simple. So, how would this all apply on computers and performance? On a development project that you may be proposing, the agreement may be that the system's response must be good, low error rate, and decent uptime. Lets say no responses above 10 seconds (not on all processes), errors under 2% in key services, and 99% availability. To achieve that Agreement, we will create multiple objectives with thresholds, such as CPU not going over 70% ever, responses times on key live processes under 3 seconds with specific load and a minimum of 2 gigs of ram always available, even unde 1000s of transactions happening per second. The indicators would be that the cpu was always at 50%, that the responses under load were 1.5 seconds on average and the system never consumed the ram too much, leaving always 4 gigs free. To close lets do a silly example to make sure everything is clear. Imagine you are on a race. The agreement is to win it. Plain and simple. To win it, your objectives could bethe following. First a fixed one. Achieve 1st place. No greater nor smaller, just 1st place. A second SLO could be to keep a pace greater than the minimum of the last race. Maybe also the race time should be better than the 2nd place, hopefully better than the record. Last, the SLIs would be your actual time, the actual time of the 2nd place, your pace during the race. and so on. As you can see, all these are very relevant for performance testing, and of course K6 takes them very much into account. With lots of functions and processes that will help you to define thresholds for your service levels. We will get deeper on the specifics for implementing them in K6 in the next episode. Stay tuned! Don't forget to keep those service levels up! That's it from me for now. Hope you learned a lot! Will see you soon! Adios! [https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli](https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli) [https://en.wikipedia.org/wiki/Service-level\_objective](https://en.wikipedia.org/wiki/Service-level_objective) [https://sre.google/sre-book/service-level-objectives/](https://sre.google/sre-book/service-level-objectives/) ## See also - [[Performance Thresholds]] - [[Set multiple thresholds]] - [[Requirements]] - [[What is a test requirement]] - [[Writing a good test requirement]]