Modeling a sample Java-based e-commerce application (Konakart)
This page provides code snippets for each Akamas construct by considering the Konakart, a Java-based e-commerce application (https://www.konakart.com/), as a reference and modeling it as a 2-tier application, with an application server and a database (MySQL) layers.
For simplicity's sake, the optimization use case is defined as follows:
Optimization scope: JVM parameters
Optimization goal: reduce the application memory footprint (i.e. heap max that can be allocated by the JVM)
Optimization constraints: no impact on service level (i.e. response times, throughput, and error rate have to be the same before/after the optimization)
System
This is the YAML file providing the system definition for the reference use case:
Since the optimization scope only considers JVM parameters, only a java component needs to be modeled.
The following snippet defines a Konakart java component based on a java-openjdk-11 component type.
name:Konakart jvmdescription:jvm layer of Konakart e-commercecomponentType:java-openjdk-11
A different optimization scope would have required a different modeling approach. For instance, a broader optimization scope including the Linux layers of both application and database and the database layer would have required 3 additional components: 2 distinct components (of the same component type) for the 2 Linux layers and 1 component for the database layer.
From a monitoring perspective, there are only 2 mandatory data sources: the JVM layer, which will provide the goal metric needed to evaluate the score (heap size), and the web application layer, which will provide the metrics needed to evaluate optimization constraints (response time, throughput and error rate). The web-application component is based on a particular component type that aims to ease the collection of end-users metrics and has no parameters attached. Generally speaking the definition of a component based on the web application component type can be handy every time an optimization foresees the execution of a performance test and it is required to evaluate the end-to-end metrics.
The following snippet defines a Konakart component based on a web-application component type.
name: Konakart
description: Web Application layer of Konakart e-commerce
componentType: Web Application
A more comprehensive approach to telemetries could include additional metrics and data sources to provide a better understanding of the system behavior. The example provided only focuses on the mandatory metrics and the components needed to model them.
Component Type
Here is a (simplified) component types definition for the reference use case.
name:java-openjdk-11description:The component type of Java OpenJDK and Oracle HotSpot version 11parameters: - name:jvm_maxHeapSizedomain:type:integerdomain: [16,102400]defaultValue:1024operators:FileConfigurator:confTemplate:-Xmx${value}M - name:jvm_gcTypedomain:type:categoricalcategories: [Serial,Parallel,ConcMarkSweep,G1]defaultValue:G1operators:FileConfigurator:confTemplate:-XX:+Use${value}GCmetrics: - name:jvm_heap_size - name:jvm_gc_time
name:Web Applicationdescription:Component-type containing the metrics representing a web application.parameters: []metrics: - name:transactions_response_time - name:transactions_throughput - name:transactions_error_rate
These component types are included in the "Java" and "Web Application" Optimization Packs and are available in any Akamas installation.
Parameters
Here is a (simplified) definition of the java parameters related to the java component type used for the reference use case.
parameters: - name:jvm_maxHeapSizedescription:Maximum heap sizeunit:megabytes - name:jvm_gcTypedescription:Type of the garbage collection algorithmunit:""
These parameters are included in the "Java" and "Web Application" Optimization Packs and are available in any Akamas installation.
Metrics
Here is a (simplified) definition of the web-application metrics related to the web-application component type used for the reference use case.
metrics: - name:transactions_response_timedescription:The average transaction response timeunit:milliseconds - name:transactions_throughputdescription:The number of transactions executed per secondunit:transactions/s - name:transactions_error_ratedescription:The percentage of transactions flagged as errorunit:percent
These parameters are included in the "Web Application" Optimization Pack and are available in any Akamas installation.
Optimizing a web application
In this study, Akamas will optimize a web application by tuning the JVM parameters. The workflow leverages NeoLoad’s load generator through the dedicated NeoLoad Web operator and the NeoLoad Web provider to gather the metrics.
Optimization setup
System
The following snippets contain the definition of the system composed by a JVM running the petstore web application.
Here’s a workflow that creates a new configuration file by interpolating the tuned parameters in a template file, restarts the application to apply the parameters, and triggers the execution of a load test:
Here’s a study in which Akamas tries to minimize to minimize the Java memory consumption by acting only on the heap size and on the type of garbage collector.
The web application metrics are used in the constraints in order to ensure the configuration does not degrade the service performances (throughput, response time, and error rate) below the acceptance level.
Setting up a Konakart environment for testing Akamas
This page describes how to setup a simple yet complete performance testing environment that you can use for running Akamas offline optimization study:
The target application is Konakart, a real-world Java-based e-commerce application
JMeter will be used to execute stress tests, with built-in sample scenarios
Prometheus will be used to monitor the environment (load test, JVM and OS metrics)
Reference Architecture
The following picture describes the high-level Akamas architecture that is enabled by this setup.
Setup Docker Swarm
First of all, install Docker on your Linux box:
sudo apt update && sudo apt install docker.io
Now enable the user ubuntu to run docker without sudo:
sudo usermod -aG docker $USER
newgrp docker
In this environment we leverage Docker Swarm, a Docker native container orchestration system. Even though in this scenario everything runs on a single machine, Swarm is handy as it provides the ability to specify container resource limits (e.g. how many CPUs and how much memory the container can use) which can be very useful from a tuning perspective.
At this point, we can initialize Docker Swarm with this simple command:
docker swarm init
You should see a message stating that Docker Swarm has been setup.
You now create a Docker network that all the containers will use to communicate:
docker stack deploy --compose-file konakart-docker/konakart/docker-compose.yml sut
You can now verify that Konakart is up and running by accessing your instance on port 8780:
Setup JMeter (optional)
Unless you plan to use a different load testing tool (such as LoadRunner Enterprise or Neotys NeoLoad), JMeter is a great choice to start using Akamas.
Setting up JMeter is straightforward as a JMeter container comes already configured with test plans built for performance testing Konakart. Moreover, JMeter is already configured with the Prometheus integration so that performance test metrics (e.g. transaction throughput and transaction response time) are collected via Prometheus Listener for JMeter. You just need to verify the ability to launch a performance test in this environment.
You can launch a first manual performance test by running the following command, where you need to replace YOUR_INSTANCE_ADDRESS with the address of your Konakart instance:
In case you see any errors (check out the Err: column), chances are that JMeter cannot contact Konakart. Please verify that your instance address is correct and relaunch the manual test until you are sure JMeter is running correctly.
Test plans
The JMeter docker image includes a couple of test plans described here below:
Ramp test plan
This test allows you to stress test Konakart with a ramp load profile. This profile is included in the ramp_test_plan.jmx file.
You can customize the profile by setting the following JMeter variables (see the example above):
THREADS, the maximum number of virtual users (default 20)
RAMP_SEC, the load test duration in seconds (default 200)
Plateau test plan
This test allows you to do a performance test of Konakart with an initial ramp-up and then with a constant load. This profile is included in the plateau_test_plan.jmx file.
You can customize the scenario by setting the following JMeter variables (see the example above):
THREADS, the maximum number of virtual users (default 20)
RAMP_UP_MIN, the ramp-up duration in minutes (default 1)
RAMP_UP_COUNT, the number of steps in the ramp (default 5)
HOLD_MIN, the plateau duration in minutes (default 5)
Setup Prometheus (optional)
Unless you plan to use a different monitoring tool (such as Dynatrace), Prometheus is a great choice to start using Akamas.
Now that Konakart and JMeter are up and running, the last step is to setup Prometheus. In this scenario, Prometheus allows you to gather any metrics you will need for your Akamas optimizations, for example, the performance test metrics measured by JMeter (e.g. transaction throughput and response time) or related to application resource usage.
This environment also includes a number of useful dashboards that you can use to monitor the application, infrastructure and load testing key metrics.
By running the following command you can launch Prometheus and Grafana, plus a set of preconfigured dashboards to monitor your load tests:
The following is a quick overview of the preconfigured dashboards that you can use to monitor the application, infrastructure and load-testing key metrics. These dashboards are available as part of the Prometheus installation.
You can view this dashboard by accessing Grafana on port 3000 of your Konakart instance.
JMeter Exporter
The JMeter dashboard allows you to monitor your performance tests.
For example, run again the JMeter performance test described before and see the results in the JMeter dashboard:
Docker Container
The Docker dashboard allows you to see the resource consumption of your containers, including the Konakart application:
JMX Exporter
The Node dashboard allows you to see the OS-level Linux performance metrics of your instance:
At this point, you have a simple test environment for your Akamas optimizations.
Knowledge Base
This guide describes how to apply the Akamas approach to the optimization of some real-world cases and how to set up a test environment for experimenting with Akamas.
Optimizing a sample Linux system
In this study, Akamas is tasked with the optimization of Linux1, a Linux-based system (Ubuntu). The study's goal is to maximize the throughput of the computations of the Sysbench CPU benchmark.
Sysbench is a suite of benchmarks for CPU, file system, memory, threads, etc… typically used for testing the performance of databases.
System1 comes with a Node Exporter that collects system metrics that Akamas consumes through a Prometheus provider. Concerning Sysbench metrics, The study uses the CSV provider to make them available to Akamas.
The study uses Sysbench to execute a performance test against System1.
Telemetry
Setup a Prometheus and a Node Exporter to monitor the System
Install the Prometheus provider
Create a provider instance:
provider:"Prometheus"config:address:"linux1"# address of the Prometheus of system1port:9090# port of the Prometheus of system1component:"linux1-linux"
4. Install the CSV File provider.
5. Create a provider instance:
provider:"CSV"config:address:"linux1"authType:"password"username:"ubuntu"auth:"[INSERT PASSWORD HERE]"protocol:scpremoteFilePattern:"/home/ubuntu/benchmark_log.csv"# the remote path of the csv with the metrics of the benchmarkcomponentColumn:"component"# which column of the csv should contain the name of the componentcsvFormat:"horizontal"metrics:- metric:"throughput"datasourceMetric:"events_per_second"
Workflow
The study uses a four-task workflow to test System1 with a new configuration:
Task Configure OS, which leverages the LinuxConfigurator operator to apply a new set of Linux configuration parameters
Task Start benchmark, which leverages the Executor operator to launch the benchmark
The following YAML file represents the complete workflow definition:
name:"workflow for linux 1"tasks- name:"Configure OS"operator:"LinuxConfigurator"arguments:component:linux1-linux- name:"Start benchmark"operator:"Executor"arguments:command:"bash /home/ubuntu/benchmark.sh"host:hostname:"linux1"username:"ubuntu"password:"[INSERT_HERE_PASSWORD]"
System
Within Akamas, System1 is modeled by a system of two components:
system1-linux, which represents the actual Linux system with its metrics and parameters and is of type Ubuntu 16.04
system1-bench, which represents the Sysbench with its metrics and is of type Sysbench
The following YAML file represents the definition of the Sysbench component type:
name:"Sysbench"description:"A component-type for Sysbench"metrics:- "throughput"# only one metric
Study
Goal: minimize the throughput of the benchmark
Windowing: take the default (compute the score for the entire duration of a trial)
Parameters selection: select only CPU scheduling parameters
Metrics selection: select only the throughput of the benchmark
Trials: 3
Steps: one baseline and one optimize
The following YAML file represents the definition of the study:
system:"system for linux1"workflow:"workflow ofr linux1"name:"linux optimization with sysbench"description:"Optimizing an Ubuntu instance with a CPU intensive benchmark: sysbench"goal:objective:minimizefunction:formula:"linux1-benchmark.throughput"metricsSelection: - "linux1-benchmark.throughput"parametersSelection: - name:"linux1-linux.os_cpuSchedMinGranularity" - name:"linux1-linux.os_cpuSchedWakeupGranularity" - name:"linux1-linux.os_CPUSchedMigrationCost" - name:"linux1-linux.os_CPUSchedChildRunsFirst" - name:"linux1-linux.os_CPUSchedLatency" - name:"linux1-linux.os_CPUSchedAutogroupEnabled" - name:"linux1-linux.os_CPUSchedNrMigrate"numberOfTrials:3steps: - name:"baseline"type:"baseline"values:linux1-linux.os_cpuSchedMinGranularity:2250000linux1-linux.os_cpuSchedWakeupGranularity:3000000linux1-linux.os_CPUSchedMigrationCost:500000linux1-linux.os_CPUSchedChildRunsFirst:0linux1-linux.os_CPUSchedLatency:18000000linux1-linux.os_CPUSchedAutogroupEnabled:1linux1-linux.os_CPUSchedNrMigrate:32 - name:"optimization"type:"optimize"numberOfExperiments:99maxFailedExperiments:25
Optimizing a Kubernetes application
In this example, we’ll optimize Online Boutique, a demo e-commerce application running on microservices, by tuning the resources allocated to a selection of pods. This is a common use case where we want to minimize the cost associated with running an application without impacting the SLO.
Notice: all the required artifacts are published in this public repository.
Environment setup
The test environment includes the following instances:
Akamas: the instance running Akamas.
Cluster: an instance hosting a Minikube cluster.
You can configure the Minikube cluster using the scripts provided in the public repository by running the command
To gather metrics about the application we will use Prometheus. It will be automatically configured by applying the artifacts in the repository with the following command:
kubectl apply -f kubernetes-online-boutique/kube/
Application and Test tool
The targeted system is Online Boutique, a microservice-based demo application. In the same namespace, a deployment running the load generator will stress the boutique and forward the performance metrics to Prometheus.
To configure the application and the load generator on your (Minikube) cluster, apply the definitions provided in the public repository by running the following command:
kubectl apply -f kubernetes-online-boutique/kube/
Optimization setup
In this section, we will guide you through the steps required to set up the optimization on Akamas.
If you have not installed the Kubernetes optimization pack yet, take a look at the Kubernetes optimization pack page to proceed with the installation.
Notice: the artifacts to create the Akamas entities can be found in the public repository, under the akamas directory.
System
System Online Boutique
Here’s the definition of the system containing our components and telemetry-instances for this example:
name:Online Boutiquedescription:The Online Boutique by Google
We’ll use a component of type WebApplication to represent at a high level the Online Boutique application. To identify the related Prometheus metrics the configuration requires the prometheus property for the telemetry service, detailed later in this guide.
The public repository contains the definition of all the services that compose Online Boutique. In this guide, for the sake of simplicity, we’ll only tune the resources of the containers in the frontend and the product-catalog pods, defined as components of type Kubernetes Container.
Here’s their definition:
name:frontenddescription:The frontend of the online boutique by GooglecomponentType:Kubernetes Containerproperties:prometheus:job:.*instance:.*name:.*pod:ak-frontend.*container:server
name:productcatalogservicedescription:The productcatalogservice of the online boutique by GooglecomponentType:Kubernetes Containerproperties:prometheus:job:.*instance:.*name:.*pod:ak-productcatalogservice.*container:server
To create the component in the system run the following command:
To better illustrate the process, here is a snippet of the template file used to update the resource limits for the frontend deployment.
apiVersion:apps/v1kind:Deploymentmetadata:name:ak-frontendnamespace:akamas-demospec:selector:matchLabels:app:ak-frontendtemplate:metadata:labels:app:ak-frontend# other definitions...spec:containers: - name:serverimage:gcr.io/google-samples/microservices-demo/frontend:v0.2.2# other definitions...resources:requests:cpu:${frontend.cpu_limit}memory:${frontend.memory_limit}limits:cpu:${frontend.cpu_limit}memory:${frontend.memory_limit}# other definitions...
The following are respectively the script to start and stop the load generator:
If you have not installed the Prometheus telemetry provider yet, take a look at the telemetry provider page Prometheus provider to proceed with the installation.
With the definition of the telemetry instance shown below, we import the end-user performance metrics provided by the load-generator, along with a custom definition of "cost" given by a weighted sum of the CPU and memory allocated for the pods in the cluster:
With this study, we want to minimize the "cost" of running the application, which, according to the definition described in the previous section, it means reducing the resources allocated to the tuned pods in the cluster. At the same time, we want the application to stay within the expected SLO, and that is obtained by defining a constraint on the response time and error rate recorded by the load generator.
To create and run the study execute the following commands:
akamas create study study.yaml
akamas start study 'Minimize Kubernetes Online Boutique cost while matching SLOs'
Optimizing a sample Java OpenJ9 application
In this example study we’ll tune the parameters of PageRank, one of the benchmarks available in the Renaissance suite, with the goal of minimizing its memory usage. Application monitoring is provided by Prometheus, leveraging a JMX exporter.
Environment setup
The test environment includes the following instances:
Akamas: instance running Akamas
PageRank: instance running the PageRank benchmark and the Prometheus monitoring service
Telemetry Infrastructure setup
To gather metrics about PageRank we will use a Prometheus and a JMX exporter. Here’s the scraper to add to the Prometheus configuration to extract the metrics from the exporter:
In this section, we will guide you through the steps required to set up the optimization on Akamas.
If you have not installed the Eclipse OpenJ9 optimization pack yet, take a look at the optimization pack page Eclipse OpenJ9 to proceed with the installation.
System
System pagerank
Here’s the definition of the system we will use to group our components and telemetry-instances for this example:
name:pagerankdescription:A system to tune the pagerank benchmark
To create the system run the following command:
akamas create system pagerank.yaml
Component jvm
We’ll use a component of type IBM J9 VM 8 to represent the JVM underlying the PageRank benchmark. To identify the JMX-related metrics in Prometheus the configuration requires the prometheus property for the telemetry service, detailed later in this guide.
This telemetry instance will be able to bind the fetched metrics to the related jvm component thanks to the prometheus attribute we previously added in its definition.
Study
The goal of this study is to find a JVM configuration that minimizes the peak memory used by the benchmark.
The optimized parameters are the maximum heap size, the garbage collector used and several other parameters managing the new and old heap areas.
We also specify a constraint stating that the GC regions can’t exceed the total heap available, to avoid experimenting with parameter configurations that can’t start in the first place.
Here’s the definition of the study:
name:Optimize PageRankdescription:Tweaking the Eclipse OpenJ9 parameters to optimize the page-rank benchmark.system:pagerankworkflow:run-pagerankgoal:objective:minimizefunction:formula:max_memoryvariables:max_memory:metric:jvm.jvm_memory_usedaggregation:maxparametersSelection: - name:jvm.j9vm_gcPolicy - name:jvm.j9vm_maxHeapSizedomain: [1250,2000] - name:jvm.j9vm_newSpaceFixeddomain: [350,2000] - name:jvm.j9vm_minFreeHeap - name:jvm.j9vm_maxFreeHeap - name:jvm.j9vm_gcThreadsparameterConstraints: - name:Max heap must always be greater than new sizeformula:jvm.j9vm_maxHeapSize > jvm.j9vm_newSpaceFixed - name:Max free always greater than min freeformula:jvm.j9vm_minFreeHeap + 0.05 < jvm.j9vm_maxFreeHeapsteps: - name:baselinetype:baselinevalues:jvm.jvm_gcType:genconjvm.jvm_maxHeapSize:2000 - name:optimizetype:optimizenumberOfExperiments:30
To create and run the study execute the following commands:
akamas create study study.yaml
akamas start study 'Optimize PageRank'
Optimizing a sample Java OpenJDK application
In this example study we’ll tune the parameters of PageRank, one of the benchmarks available in the Renaissance suite, with the goal of minimizing its memory usage. Application monitoring is provided by Prometheus, leveraging a JMX exporter.
Environment setup
The test environment includes the following instances:
Akamas: instance running Akamas
PageRank: instance running the PageRank benchmark and the Prometheus monitoring service
Telemetry Infrastructure setup
To gather metrics about PageRank we will use a Prometheus and a JMX exporter. Here’s the scraper to add to the Prometheus configuration to extract the metrics from the exporter:
In this section, we will guide you through the steps required to set up the optimization on Akamas.
If you have not installed the Java OpenJDK optimization pack yet, take a look at the optimization pack page Java OpenJDK to proceed with the installation.
System
System pagerank
Here’s the definition of the system we will use to group our components and telemetry instances for this example:
name:pagerankdescription:A system to tune the pagerank benchmark
To create the system run the following command:
akamascreatesystempagerank.yaml
Component jvm
We’ll use a component of type Java OpenJDK 11 to represent the JVM underlying the PageRank benchmark. To identify the JMX-related metrics in Prometheus the configuration requires the prometheus property for the telemetry service, detailed later in this guide.
This telemetry instance will be able to bind the fetched metrics to the related jvm component thanks to the prometheus attribute we previously added in its definition.
Study
The goal of this study is to find a JVM configuration that minimizes the peak memory used by the benchmark.
The optimized parameters are the maximum heap size, the garbage collector used and several other parameters managing the new and old heap areas.
We also specify a constraint stating that the GC regions can’t exceed the total heap available, to avoid experimenting with parameter configurations that can’t start in the first place.
Here’s the definition of the study:
name:Optimize PageRankdescription:Tweaking the JVM parameters to optimize the page-rank benchmark.system:pagerankworkflow:run-pagerankgoal:objective:minimizefunction:formula:max_memoryvariables:max_memory:metric:jvm.jvm_memory_usedaggregation:maxparametersSelection: - name:jvm.jvm_gcType - name:jvm.jvm_maxHeapSizedomain: [1250,2000] - name:jvm.jvm_newSizedomain: [350,2000] - name:jvm.jvm_survivorRatio - name:jvm.jvm_maxTenuringThresholdparameterConstraints: - name:Max heap must always be greater than new sizeformula:jvm.jvm_maxHeapSize > jvm.jvm_newSizesteps: - name:baselinetype:baselinevalues:jvm.jvm_gcType:G1jvm.jvm_maxHeapSize:2000 - name:optimizetype:optimizenumberOfExperiments:30
To create and run the study execute the following commands:
In this example study we’ll tune the parameters of SparkPi, one of the examples applications provided by most of the Apache Spark distributions, to minimize its execution time. Application monitoring is provided by the Spark History Server APIs.
Environment setup
The test environment includes the following instances:
Akamas: instance running Akamas
Spark cluster: composed of instances with 16 vCPUs and 64 GB of memory, where the Spark binaries are installed under /usr/lib/spark. In particular, the roles are:
1x master instance: the Spark node running the resource manager and Spark History Server (host: sparkmaster.akamas.io)
2x worker instances: the other instances in the cluster
Telemetry Infrastructure setup
To gather metrics about the application we will leverage the Spark History Server. If it is not already running, start it on the master instance with the following command:
Application and Test tools
To make sure the tested application is available on your cluster and runs correctly, execute the following commands:
Optimization setup
In this section, we will guide you through the steps required to set up on Akamas the optimization of the Spark application execution.
System
System spark
Here’s the definition of the system we will use to group our components and telemetry instances for this example:
To create the system run the following command:
Component sparkPi
In the snippet shown below, we specify:
the field properties required by Akamas to connect via SSH to the cluster master instance
the parameters required by spark-submit to execute the application
the sparkApplication flag required by the telemetry instance to associate the metrics from the History Server to this component
To create the component in the system run the following command:
Workflow
The workflow used for this study contains only a single stage, where the operator submits the application along with the Spark parameters under test.
Here’s the definition of the workflow:
To create the workflow run the following command:
Telemetry
Here’s the definition of the component, specifying the History Server endpoint:
To create the telemetry instance in the system run the following command:
This telemetry instance will be able to bind the fetched metrics to the related sparkPi component thanks to the sparkApplication attribute we previously added in its definition.
Study
The goal of this study is to find a Spark configuration that minimizes the execution time for the example application.
To achieve this goal we’ll operate on the number of executor processes available to run the application job, and the memory and CPUs allocated for both driver and executors.
The domains are configured so that the single driver/executor process does not exceed the size of the underlying instance, and the constraints make it so that the application overall does not require more resources than the ones available in the cluster, also taking into account that some resources must be reserved for other services such as the cluster manager.
Note that this study uses two constraints on the total number of resources to be used by the spark application. This example refers to a cluster of three nodes with 16 cores and 64 GB of memory each, and at least one core per instance should be reserved for the system.
Here’s the definition of the study:
To create and run the study execute the following commands:
Leveraging Ansible to automate AWS instance management
EC2 instance creation
EC2 instance termination
EC2 instance resizing
Instance Creation
The following example playbook provisions an EC2 instance using the latest Ubuntu 18-04 LTS image and then waits for it to be available.
The playbook requires the following set of arguments:
key: the name of the SSH key pair to use
Name: the instance name
security_group: the name of the AWS security group
region: the selected AWS region
intance_type: type of instance to provision
volume_size: size of the attached volume
Instance Termination
The following playbook terminates all instances with the specified name (or any other tag).
It requires the following arguments:
instance_name: the name instances name
region: the selected AWS region
Instance Resizing
It makes use of a list of arguments:
instance_name: your instance name
region: the selected AWS region
For a successful workflow it requires:
The instance to exist
The instance to be unique
Optimizing a MongoDB server instance
In this example study, we are going to optimize a MongoDB single server instance by setting the performance goal of maximizing the throughput of operations toward the database.
Environment setup
Hosts and ports
You can use a single host for both MongoDB and YCSB but, in the following example, we replicate a common pattern in performance engineering by externalizing the load injection tool into a separate instance to avoid performance issues and measurement noise.
Notice: in the following, the assumption is to be working with Linux hosts.
Prometheus and exporters
To correctly extract MongoDB metrics we can leverage a solution like Prometheus, paired with the MongoDB Prometheus exporter. To do so we would need to:
Install the MongoDB Prometheus exporter on mongo.mycompany.com
Install and configure Prometheus on ycsb.mycompany.com
Install the MongoDB Prometheus exporter
By default, the exporter will expose MongoDB metrics on port 9100
Install and configure Prometheus
The following YAML fileprometheus.yaml is an example of the Prometheus configuration that you can use.
System
Since we are interested in tuning MongoDB by acting on its configuration parameters and by observing its throughput measured using YCSB, we need two components:
Here’s the definition of our system (system.yaml):
Here’s the definition of our mongo component (mongo.yaml):
Here’s the definition of our ycsb component (ycsb.yaml):
We can create the system by running:
We can then create the components by running:
Workflow
Configure MongoDB with the configuration parameters decided by Akamas
Test the performance of the application
Prepare test results
Notice: here we have omitted the Cleanup step because it is not necessary for the context of this study.
Configure MongoDB
We can define a workflow task that uses the FileConfigurator operator to interpolate Akamas parameters into a MongoDB configuration script:
Here’s an example of a templated configuration script for MongoDB:
We can add a workflow task that actually executes the MongoDB configuration script produced by the FileConfigurator:
In each task, we leveraged the reference to the "mongo" component to fetch from its properties all the authentication info to ssh into the right machine e let the FileConfigurator and Executor do their work
Test the performance of the application
We can define a workflow task that uses the Executor operator to launch the YCSB benchmark against MongoDB:
Here’s an example of a launch script for YCSB:
Prepare test results
We can define a workflow task that launches a script that parses the YCSB results into a CSV file (Akamas will process the CSV file and then extract performance test metrics):
Complete workflow
By putting together all the tasks defined above we come up with the following workflow definition (workflow.yaml):
We can create the workflow by running:
Telemetry
Prometheus
Notice: the fact that the instance definition contains the specification of Prometheus queries to map to Akamas metrics is temporary. In the next release, these queries will be embedded in Akamas.
By default, $DURATION$ will be replaced with 30s. You can override it to your needs by setting a duration property under prometheus within your mongo component
We can now create the telemetry instance and attach it to our system by running:
CSV
To start using the provider, we need to define a telemetry instance (csv.yaml):
We can create the telemetry instance and attach it to our system by running:
Study
Our goal for optimizing MongoDB is to maximize its throughput, measured using a performance test executed with YCSB.
Goal
Here’s the definition of the goal of our study, to maximize the throughput:
Windowing
It is important that the throughput of our MongoDB instance should be considered valid only when it is stable, for this reason, we can use the stability windowing policy. This policy identifies a period of time with at least 100 samples with a standard deviation lower than 200 when the application throughput is maximum.
Parameters to optimize
We are going to optimize every MongoDB parameter:
Steps
We are going to add to our study two steps:
A baseline step, in which we set a cache size of 1GB and use the default values for all the other MongoDB parameters
An optimize step, in which we perform 100 experiments to generate the best configuration for MongoDB
Here’s what these steps look like:
Complete study
Here’s the study definition (study.yaml) for optimizing MongoDB:
You can create the study by running:
You can then start it by running:
Optimizing a sample application running on AWS
In this example, you will go through the optimization of a Spark based PageRank algorithm on AWS instances. We’ll be using a PageRank implementation included in Renaissance, an industry-standard Java benchmarking suite developed by Oracle Labs, tweaking both Java and AWS parameters to improve the performance of our application.
Environment setup
For this example, you’re expected to use two dedicated machines:
an Akamas instance
a Linux-based AWS EC2 instance
The Linux-based instance will run the application benchmark, so it requires the latest open-jdk11 release
Telemetry Infrastructure setup
For this study you’re going to require the following telemetry providers:
Application and Test tool
Since the application consists of a jar file only, the setup is rather straightforward; just download the binary in the ~/renaissance/ folder:
In the same folder upload the template file launch.benchmark.sh.temp, containing the script that executes the benchmark using the provided parameters and parses the results:
Optimization setup
In this section, we will guide you through the steps required to set up the optimization on Akamas.
Optimization packs
This example requires the installation of the following optimization packs:
System
Our system could be named renaissance after its application, so you’ll have a system.yaml file like this:
Then create the new system resource:
The renaissance system will then have three components:
A benchmark component
A Java component
An EC2 component, i.e. the underlying instance
Java component
Create a component-jvm.yaml file like the following:
Then type:
Benchmark component
Since there is no optimization pack associated with this component, you have to create some extra resources.
A metrics.yaml file for a new metric tracking execution time:
A component-type benchmark.yaml:
The component pagerank.yaml:
Create your new resources, by typing in your terminal the following commands:
EC2 component
Create a component-ec2.yaml file like the following:
Then create its resource by typing in your terminal:
Workflow
The workflow in this example is composed by three main steps:
Update the instance type
Run the application benchmark
Stop the instance
In detail:
Update the instance size
Generate the the playbook file from the template
Update the instance using the playbook
Wait for the instance to be available
Run the application benchmark
Configure the benchmark Java launch script
Execute the launch script
Parse PageRank output to make it consumable by the CSV telemetry instance
Stop the instance
Configure the playbook to stop an instance with a specific instance id
Run the playbook to stop the instance
The following is the template of the Ansible playbook:
The following is the workflow configuration file:
Telemetry
Prometheus
The prometheus.yml file, located in your Prometheus folder:
The config.yml file you have to create in the ~/renaissance folder:
Now you can create a prometheus-instance.yaml file:
Then you can install the telemetry instance:
CSV - Telemetry instance
Create a telemetry-csv.yaml file to read the benchmark output:
Then create the resource by typing in your terminal:
Study
Here we provide a reference study for AWS.
As we’ve anticipated, the goal of this study is to optimize a sample java application, the PageRank benchmark you may find in the renaissance benchmark suite by Oracle.
Our goal is rather simple: minimizing the product between the benchmark execution time and the instance price, that is, finding the most cost-effective instance for our application.
Create a study.yaml file with the following content:
Then create the corresponding Akamas resource and start the study:
Optimizing an Oracle Database for an e-commerce service
Environment Setup
Environment
For this study, we will use three dedicated machines:
oradb.mycompany.com, hosting an Oracle Database 19c instance
konakart.mycompany.com, running the KonaKart Community Edition service
Refer to the following links to install and configure KonaKart Community Edition:
Prometheus and exporters
Install the OracleDB Prometheus exporter
Through the OracleDB Prometheus exporter, we can publish as metrics the results of the arbitrary queries defined in the configuration file. In our case, we’ll use it to extract valuable performance metrics from Oracle’s Dynamic Performance (V$) Views.
The exporter will publish the metrics on the specified port 9161.
Here’s the metrics file used to run the exporter:
Install and configure Prometheus
Using the following snippet we configure Prometheus to fetch metrics from:
the JMeter exporter exposing the load-generator stats
the OracleDB exporter monitoring the database
Setup the load-generator
The load generator runs containerized on the akamas.mycomopany.com instance using the attached Konakart_optimizePerf.jmx configuration file.
The provided run_test.sh wraps the command to execute the test, and requires as an argument the URL of the target KonaKart instance.
Optimization Setup
System
Our modeled system includes the following components:
The oracle component that models the Oracle Database instance on oradb.mycompany.com, whose parameters are the targets of our optimization
The webapp component that models the KonaKart service running on konakart.mycompany.com, providing the performance metrics used to validate the system’s SLOs
The first step is defining the system (system.yaml):
Here’s the definition of our oracle component (oracle.yaml), including the parameters needed to connect to the database instances and the filters to fetch metrics from Prometheus.
Notice: in order to update the init parameter the user requires the ALTER SYSTEM privilege.
Here’s the definition of the konakart component (konakart.yaml), containing the filters to fetch the metrics from Prometheus:
We can create the system by running the following command:
We can then create the components by running the following commands:
Telemetry
We can now create the telemetry instance and attach it to our system by running:
Workflow
This section outlines the steps performed during the execution of the experiments.
Stop KonaKart
Attached you can find the referenced script check_konakart_stop.sh:
Configure the Oracle instance
Attached you can find the referenced script check_db.sh:
and restart_db.sh:
Restart the KonaKart instance
Attached you can find the referenced script:
Run the workload
Complete workflow
By putting together all the tasks defined above we come up with the following workflow definition (workflow.yaml):
We can create the workflow by running:
Study
This study aims to minimize the memory allocated for the Oracle database while under a simulated load of the typical traffic, without impacting the SLOs.
This section provides a step-by-step description of the study definition.
Goal
Here’s the definition of the goal for our study, which is to minimize the memory allocated by Oracle to the SGA and PGA memory areas.
The constraints ensure that any tested configuration that does not operate within the defined SLOs is flagged as not valid. In particular, the followings are required:
the peak error rate must not exceed 5 errors per seconds
the transaction throughput must not decrease more than 10% with respect to the baseline
the response time must not increase more than 20% with respect to the baseline
Windowing
We define a window to consider only the data points after the ramp-up time of the load test:
Parameters to optimize
For this study, we are trying to optimize the size of the two main memory areas, meaning the Program Global Area and the Shared Global Area.
Given our goal, we set the domains of the parameters to explore only sizes smaller than the baseline.
The following constraint prevents Akamas from exploring configurations that we already know Oracle won’t validate:
Steps
We are going to add to our study two steps:
A baseline step, in which we configure the default values for the memory parameters as discovered from previous manual executions.
An optimization step, where we perform 200 experiments to search the set of parameters that best satisfies our goal.
Here’s what these steps look like:
Complete study
Here’s the study definition (study.yaml) for optimizing the Oracle instance:
You can create the study by running:
You can then start it by running:
Guidelines for optimizing AWS EC2 instances
This page provides a list of best practices when optimizing applications on AWS EC2 instances with Akamas.
Environment setup
Before planning out an AWS study you must first ensure you have all the rights to effectively launch it.
This means you have to:
Policies
Policies allow instance manipulation and access by being attached to users, group or AWS resources.
AWS Policies
Here we provide some basic resource-based permissions required in our scope:
EC2 instance start
EC2 instance stop
EC2 instance reboot
EC2 instance termination
EC2 instance description
EC2 instance manipulation
Security Groups
Security groups control inbound and outbound traffic to and from your AWS instances.
In your typical optimization scenario the security group should allow inbound connections on SSH and any other relevant port, including the ones used to gather the telemetry, from the Akamas instance to the ones in the tuned system.
Workflows setup
Notice that:
The study environment has to be restored to its original configuration between experiments. While that is quite simple to achieve when creating and terminating instances, this may require additional steps in a resizing scenario.
The deletion and creation of new instances determine changes in ECDSA host keys.
This may be interpreted as DNS spoofing from the Akamas instance, so consider overriding the default settings in such contexts.
Telemetry setup
Optimizing an Oracle Database server instance
In this example, we are going to tune the initialization parameters of an Oracle Database server instance in order to maximize its throughput while stressed by a load generator.
Environment setup
Environment
For the purpose of this experiment we are going to use two dedicated machines:
We assume to be working with Linux hosts
Prometheus and exporters
Install the OracleDB Prometheus exporter
The OracleDB Prometheus exporter publishes as metrics the results of the queries defined in the configuration file. In our case, we’ll use it to extract valuable performance metrics from Oracle’s Dynamic Performance (V$) Views.
The exporter will publish the metrics on port 9161.
Here’s the example metrics file used to run the exporter:
Install and configure Prometheus
In order to configure the OracleDB exporter you can add the following snippet to the configuration file:
Optimization setup
System
In order to model the system composed of the tuned database and the workload generator we need two different components:
For the tpcc component, we’ll need first to define some custom metrics and a new component-type. The following is the definition of the metrics (tpcc-metrics.yaml):
The following is the definition of the new component-type (tpcc-ctype.yaml):
We can then create the new component type running the commands:
As a next step, we can proceed then with the definition of our system (system.yaml):
Here’s the definition of our oracle component (oracle.yaml):
Here’s the definition of the tpcc component (tpcc.yaml):
We can create the system by running:
We can then create the components by running:
Telemetry
Prometheus
We can now create the telemetry instance and attach it to our system by running:
CSV
We can create the telemetry instance and attach it to our system by running:
Workflow
Remove previous executions' data
Configure the Oracle instance
Restart the instance
Run the workload
Prepare test results
Where tpcc_parse_csv.sh is the following script:
Complete workflow
By putting together all the tasks defined above we come up with the following workflow definition (workflow.yaml):
We can create the workflow by running:
Study
The objective of this study is to maximize the transaction throughput while stressed by the TPC-C load generator, and to achieve this goal the study will tune the size of the most important areas of the Oracle instance.
Goal
Here’s the definition of the goal for our study, which is to maximize the tpcc.throughput metric:
Windowing
We define a window in order to consider only the data points after the ramp-up time of the load test:
Parameters to optimize
For this study, we are trying to achieve our goal by tuning the size of several areas in the memory of the database instance. In particular, we will tune the overall size of the Program Global Area (containing the work area of the active sessions) and the size of the components of the Shared Global Area.
The domains are configured to explore, for each parameter, the values around the default values.
Constraints
The following constraint allows the study to explore different size configurations without exceeding the maximum overall memory available for the instance:
Steps
We are going to add to our study two steps:
A baseline step, in which we configure the default values for the memory parameters as discovered from previous manual executions.
An optimization step, where we perform 200 experiments to search the set of parameters that best satisfies our goal.
The baseline step contains some additional parameters (oracle.memory_target, oracle.sga_target) that are required by Oracle in order to disable the automatic management of the SGA components.
Here’s what these steps look like:
Complete study
Here’s the study definition (study.yaml) for optimizing the Oracle instance:
You can create the study by running:
You can then start it by running:
Optimizing cost of a Kubernetes application while preserving SLOs in production
In this example, you will use Akamas live optimization to minimize the cost of a Kubernetes deployment, while preserving application performance and reliability requirements.
Environment setup
In this example, you need:
an Akamas instance
a Kubernetes cluster, with a deployment to be optimized
the kubectl command installed in the Akamas instance, configured to access the target Kubernetes and with privileges to get and update the deployment configurations
a supported telemetry data source (e.g. Prometheus or Dynatrace) configured to collect metrics from the target Kubernetes cluster
Optimization setup
Optimization packs
This example leverages the following optimization packs:
System
The system represents the Kubernetes deployment to be optimized (let's call it "frontend"). You can create a system.yaml manifest like this:
Create the new system resource:
The system will then have two components:
A Kubernetes container component, which contains container-level metrics like CPU usage and parameters like CPU limits
A Web Application component, which contains service-level metrics like throughput and response time
In this example, we assume the deployment to be optimized is called frontend, with a container named server, and is located within the boutique namespace. We also assume that Dynatrace is used as a telemetry provider.
Kubernetes component
Create a component-container.yaml manifest like the following:
Then run:
Now create a component-webapp.yaml manifest like the following:
Then run:
Workflow
The workflow in this example is composed of three main steps:
Update the Kubernetes deployment manifest with the Akamas recommended deployment parameters (CPU and memory limits)
Apply the new parameters (kubectl apply)
Wait for the rollout to complete
Sleep for 30 minutes (observation interval)
Create a workflow.yaml manifest like the following:
Then run:
Telemetry
Create the telemetry.yamlmanifest like the following:
Then run:
Study
In this live optimization:
the goal is to reduce the cost of the Kubernetes deployment. In this example, the cost is based on the amount of CPU and memory limits (assuming requests = limits).
the approval mode is set to manual, a new recommendation is generated daily
to avoid impacting application performance, constraints are specified on desired response times and error rates
to avoid impacting application reliability, constraints are specified on peak resource usage and out-of-memory kills
the parameters to be tuned are the container CPU and memory limits (we assume requests=limits in the deployment file)
Create a study.yaml manifest like the following:
Then run:
You can now follow the live optimization progress and explore the results using the Akamas UI for Live optimizations.
Optimizing a live full-stack deployment (K8s + JVM)
Guidelines for optimizing Oracle RDS
This page provides a list of best practices when optimizing an Oracle RDS with Akamas.
Optimization setup
System setup
Workflow setup
Where the following is an example of the configuration template oraconf.template:
The following script rds_update.sh updates the configuration. It requires the name of the target DB parameter group and path of the temporary folder containing the generated configuration:
The following script rds_reboot.sh restarts the RDS instance with the provided id:
Optimizing a MySQL server database running Sysbench
In this example study, we are going to optimize a MySQL instance by setting the performance goal of maximizing the throughput of operations towards the database.
As regards the workload generation, in this example we are going to use Sysbench, a popular open-source benchmarking suite.
Environment Setup
In order to run the Sysbench suite against a MySQL installation, you need to first install and configure the two software. In the following , we will assume that both MySQL and Sysbench will run on the same machine, to obtain more significant results in terms of performance you might want to run them on separate hosts.
A set of scripts is provided to support all the setup steps.
MySQL Installation
To install MySQL please follow the official documentation. In the following, we will make a few assumptions on the location of the configuration files, the user running the server, and the location of the datafiles. These assumptions are based on a default installation of MySQL on an Ubuntu instance performed via apt.
Configuration file: /etc/mysql/conf.d/mysql.cnf
MySQL user: mysql
MySQL root user password: root
This is a template for the configuration file mysql.cnf.template
If your installation of MySQL has different default values for these parameters please update the provided scripts accordingly.
Sysbench Installation
To install Sysbench on an ubuntu machine run the following command
To verify your installation of Sysbench and initialize the database you can use the scripts provided here below and place them in the /home/ubuntu/scripts folder. Move in the folder, make sure MySQL is already running, and run the init-db.sh script.
This is the init-db.sh script:
This script will:
connect to your MySQL installation
create a sbtest database for the test
run the Sysbench data generation phase to populate the database
The init-db.sh script contains some information on the amount of data to generate. The default setting is quite small and should be used for testing purposes. You can then modify the test to suit your benchmarking needs. If you update the script please also update the run_benchmark.sh script accordingly.
Optimization Setup
Here follow a step by step explanation of all the required configuration for this example. You can find attached a zip file that contains all of the YAML files for your convenience.
System
In this example, we are interested in optimizing MySQL settings and measuring the peak throughput measured using Sysbench. Hence, we are going to create two components:
A mysql component which represents the MySQL instance, including all the configuration parameters
A Sysbenchcomponent which represents Sysbench and contains the custom metrics reported by the benchmark
The Sysbench component
MySQL is a widespread technology and Akamas provides a specific Optimization Pack to support its optimization. Sysbench, on the other hand, is a benchmark application and is not yet supported by a specific optimization pack. In order to use it in our study, we will need to define its metrics first. This operation can be done once and the created component type can be used across many systems.
First, build a metrics.yamlfile with the following content:
You can now create the metrics by issuing the following command:
Finally, create a file named sysbench.yaml with the following definition of the component:
You can now create the component by issuing the following command:
Model the system
Here’s the definition of our system (system.yaml):
Here’s the definition of our mysql component (mysql.yaml):
Please make sure the component properties are correct for your environment (e.g. hostname, username, key, file paths, etc.).
Here’s the definition of our Sysbench component (sysbench.yaml):
We can create the system by running:
We can then create the components by running the following commands:
Workflow
A workflow for optimizing MySQL can be structured in 6 tasks:
Reset Sysbench data
Configure MySQL
Restart MySQL
Launch the benchmark
Parse the benchmark results
Here below you can find the scripts that codify these tasks.
This is the restart-mysql.sh script:
This is the clean_bench.sh script:
This is the run_test.sh script:
This file parse_csv.sh script:
Here is the complete Akamas workflow for this example (workflow.yaml):
You can create the workflow by running:
Telemetry
This telemetry provider can be installed running:
To start using the provider, we need to define a telemetry instance (csv.yaml):
Please make sure the telemetry configuration is correct for your environment (e.g. hostname, username, key, file paths, etc.).
You can create the telemetry instance and attach it to the system by running:
Study
In this example, we are going to leverage Akamas AI-driven optimization capabilities to maximize MySQL database transaction throughput, as measured by the Sysbench benchmark.
Here is the Akamas study definition (study.yaml):
You may need to update some parameter domains based on your environment (e.g. InnoDB buffer pool size maximum value depends on your server available memory)
You can create the study by running:
You can then start it by running:
You can now follow the study progress using the UI and explore the results using the Analysis and Metrics tabs.
Optimizing a MySQL server database running OLTPBench
In this example study, we are going to optimize a MySQL instance by setting the performance goal of maximizing the throughput of operations towards the database.
Environment Setup
In order to run the OLTP Benchmark suite against a MySQL installation, you need to first install and configure the two software. In the following, we will assume that both MySQL and OLTP will run on the same machine, to obtain more significant results in terms of performance you might want to run them on separate hosts.
MySQL Installation
To install MySQL please follow the official documentation. In the following, we will make a few assumptions on the location of the configuration files, the user running the server, and the location of the datafiles. These assumptions are based on a default installation of MySQL on an Ubuntu instance performed via apt.
Datafile location: /var/lib/mysql
Configuration file: /etc/mysql/conf.d/mysql.cnf
MySQL user: mysql
MySQL root user password: root
This is a template for the configuration file mysql.cnf.template
If your installation of MySQL has different default values for these parameters please update the provided scripts accordingly.
OLTP Installation
To verify your installation of OLTP and initialize the database you can download the following set of scripts and place them in the /home/ubuntu/scripts folder. Move in the folder and run the init-db.sh script.
This is the init-db.sh script:
This script will:
connect to your MySQL installation
create a resourcestresser database for the test
run the OLTP data generation phase to populate the database
backup the initialized database under /tmp/backup
The resourcestresser.xml file contains the workload for the application. The default setting is quite small and should be used for testing purposes. You can then modify the test to suit your benchmarking needs.
Optimization Setup
Here follow a step-by-step explanation of all the required configurations for this example.
System
In this example, we are interested in optimizing MySQL settings and measuring the peak throughput measured using OLTPBench. Hence, we are going to create two components:
A mysql component which represents the MySQL instance, including all the configuration parameters
An OLTP component which represents OLTPBench and contains the custom metrics reported by the benchmark
The OLTP component
MySQL is a widespread technology and Akamas provides a specific Optimization Pack to support its optimization. OLTP, on the other hand, is a benchmark application and is not yet supported by a specific optimization pack. In order to use it in our study, we will need to define its metrics first. This operation can be done once and the created component type can be used across many systems.
First, build a metrics.yamlfile with the following content:
You can now create the metrics by issuing the following command:
Finally, create a file named resourcestresser.yaml with the following definition of the component:
You can now create the metrics by issuing the following command:
Model the system
Here’s the definition of our system (system.yaml):
Here’s the definition of our mysql component (mysql.yaml):
Here’s the definition of our OLTP component (oltp.yaml):
We can create the system by running:
We can then create the components by running:
Workflow
A workflow for optimizing MySQL can be structured into 6 tasks:
Reset OLTPBench data
Configure MySQL
Restart MySQL
Launch the benchmark
Parse the benchmark results
Here below you can find the scripts that codify these tasks.
This is the restart-mysql.sh script:
This is the clean_bench.sh script:
This is the run_test.sh script:
This file parse_csv.sh script:
Here is the complete Akamas workflow for this example (workflow.yaml):
You can create the workflow by running:
Telemetry
This telemetry provider can be installed by running:
To start using the provider, we need to define a telemetry instance (csv.yaml):
Please make sure the telemetry configuration is correct for your environment (e.g. hostname, username, key, file paths, etc.).
You can create the telemetry instance and attach it to the system by running:
Study
In this example, we are going to leverage Akamas AI-driven optimization capabilities to maximize MySQL database query throughput, as measured by the OLTPBench benchmark.
Here is the Akamas study definition (study.yaml):
You can create the study by running:
You can then start it by running:
You can now follow the study progress using the UI and explore the results using the Analysis and Metrics tabs.
We’ll use a component of type to represent the application running on the Apache Spark framework 2.3.
If you have not installed the Spark History Server telemetry provider yet, take a look at the telemetry provider page to proceed with the installation.
is an open-source software automation tool suited for instance configuration and provisioning, enabling an Infrastructure as Code approach to the Cloud.
In this page we provide a set of templates to perform the most common task to tune EC2 instance types with Akamas, such as:
Refer to the and to the for more details, and make sure to check the concepts behind to build a robust automation.
The orchestrator requires access to an account or role linked to the correct policies; this requires managing and having access to the required security groups.
You can update the ec2_ami_info task to query for a different family or specify directly the id under ec2.image.
When executing the script we must assign the following arguments as :
To apply the EC2 parameters from the selected by the Akamas engine you can generate the playbook arguments through a template like the following one, where ec2 is the name of the component:
Instance resizing is a little trickier to deploy as it requires you to and setup the .
The following playbook provides a simple way to stop, update and restart your instance: it is intended as a building block for more elaborate workflows.
To apply the EC2 parameters from the selected by the Akamas engine you can generate the playbook arguments through a template like the following, where ec2 is the name of the component:
Concerning performance tests, we are going to employ , a popular benchmark created by Yahoo for testing various NoSQL databases.
To extract MongoDB metrics, we are going to spin up a instance and we are going to use the .
for the MongoDB server instance (port 27017) and the MongoDB Prometheus exporter (port 9100)
for YCSB and Prometheus (port 9090)
You can check how to install the exporter . On Ubuntu you can use the system package manager:
You can check how to configure Prometheus ; by default, it will run on port 9090.
A mongo component which represents the MongoDB instance all the configuration parameters and maps directly to
A ycsb component which represents YCSB, in particular, it "houses" the metrics of the performance test, which can be used as parts of the goal of a study. This component maps directly to
As described in the page, a workflow for optimizing MongoDB can be structured in three main steps:
Since we are employing Prometheus to extract MongoDB metrics, we can leverage the to start ingesting data-points into Akamas. To use the Prometheus provider we need to define a telemetry-instance (prom.yaml):
Beyond MongoDB metrics, it is important to ingest into Akamas metrics related to the performance tests run with YCSB, in particular the throughput of operations. To achieve this we can leverage the which parses a CSV file to extract relevant metrics. The CSV file we are going to parse with the help of the provider is the one produced in the last task of the workflow of the study.
The Akamas instance requires provisioning and manipulating instances, therefore it requires to be enabled to do so by setting , integrating with orchestration tools (such as ) and an inventory linked to your AWS EC2 environment.
to parse the results of the benchmark
to monitor the instance
to extract instance price
The suite provides the benchmark we’re going to optimize.
You may find further info about the suite and its benchmarks in the .
To manage the instance we are going to integrate a very simple in our workflow: the will replace the parameters in the template file in order to generate the code run by the as explained in the page.
If you have not installed the Prometheus telemetry provider or the CSV telemetry provider yet, take a look at the telemetry provider pages and to proceed with the installation.
Prometheus allows us to gather jvm execution metrics through the jmx exporter: download the java agent required to gather metrics from , then update the two following files:
You may find further info on exporting java metrics to Prometheus .
In this example study, we will tune the initialization parameters of an Oracle Database server instance to minimize the memory required for running , a popular Java e-commerce service, without significantly impacting the responsiveness of the whole system.
We’ll use to stress the system for the test, while we will leverage the to extract the metrics.
akamas.mycompany.com, which generates the workload using JMeter and will host the instance
: install and configure the service
: install the demo dataset
For this use case, we provisioned the database on a VM on , which allows us to easily provision licensed instances on demand.
We can spin up the exporter using the using the following command, where cust-metrics.toml is our custom metrics file:
For a complete guide on how to configure and manage Prometheus refer to the .
Since we are using Prometheus to extract the database metrics we can leverage the which already includes the queries needed for the Oracle and JMetric queries for the metrics we need. To use the Prometheus provider we need to define a telemetry instance (prom.yaml):
Using an we run a command to stop the KonaKart instance using the script provided with the installation, then check the service is not running anymore with a custom script:
Using the to update the Oracle initialization parameters with the new configuration. Then with the , we run some custom scripts to restart the database instance to apply the new parameters and check for a successful startup. Additionally, in case of a failed startup, the script of the last task restores a backup of the default configuration file (spfile), restarts the database, and returns an error code to notify Akamas that the tested configuration is invalid:
We then define the tasks that restart the KonaKart service and check it is running correctly:
Finally, we define a task that uses the to run the JMeter load test against the KonaKart instance:
Check your
Check your
The suggested best practice to avoid impacting other critical environments, like production, is to in order to isolate the Akamas instance and the tested resources.
Whether the case, you’re also required to comply with the for instance manipulation. In the following, we show a standard, tag and resource-based policy.
are indeed a robust way to scope your Akamas optimizations: you can invariantly refer to instances and sets of instances across generations and stack them for more elaborate conditions.
on your EC2 resources neatly avoids collateral effects during your experiments.
In order to correctly enable the provisioning and manipulation of EC2 instances you have to set the correct . Notice that AWS offers several .
Consider using in order to enforce finer access control for the automation tools, as shown in the example above.
Refer to the for a complete list of AWS EC2 policies.
Akamas workflows managing EC2 instances usually expect you to either create throwaway instances or resize already existing ones. This provides an example for both cases: all you need to do is to apply the by making the instance type and instance size parameters tunable.
The comes in handy in-between instance provisioning. Creating an instance and more so waiting for its DNS to come up may take a while, so forcing a few minutes to wait is usually worth it. This operator is a viable option if you can’t force it through an automation tool.
The is better suited for launching benchmarks and applications rather than for setting up your instance. It’s better to use automation tools or ready-to-use AMIs to set up all required packages and dependencies, as the workflow should cover your actual study case.
While the CloudWatch Exporter is a natural choice for EC2 instance monitoring, EC2 instances are often Linux instances, so it’s useful to use the through the paired with the Node exporter every time you can directly access the instance.
For the workload, we’ll use the , a popular transaction processing benchmarking suite, while to extract the metrics we are going to leverage the .
, hosting a single Oracle 18c XE instance running inside a docker container (provisioned using the scripts on the )
, that generates the workload using and will host the instance
We can spin up the exporter using the using the following command, where cust-metrics.toml is our custom metrics file:
You can check how to configure Prometheus ; by default, it will run on port 9090.
An oracle component that represents the Oracle Database instance and maps directly to .
A tpcc component that represents the TPC-C workload from the OLTPBench suite and maps to .
Since we are using Prometheus to extract the database metrics we can leverage the , which already includes the queries needed for the Oracle metrics we need. To use the Prometheus provider we need to define a telemetry instance (prom.yaml):
Other than the telemetry of the Oracle instance, we need also the metrics in the output CSVs from the TPC-C workload runs. To ingest these metrics we can leverage the , defining the following telemetry instance (csv.yaml):
Using an we run a command to clean the results folder that may contain files from previous executions
We define a task that uses the to update the Oracle initialization parameters:
We define a task that uses the that reboots the Oracle container for the parameters that need a restart to take effect:
We define a task that uses the to launch the TPC-C benchmark against the Oracle instance:
We define a workflow task that runs a script that parses the TPC-C output files and generates a file compatible with the :
The following study shows how to optimize the cost of a Kubernetes deployment considering also some JMV parameters in the optimization. Notice that, except for the JVM portion, the study is the same as the study in the example .
Note that in this study a present step has been specified with the specific value (category) of categorical parameters, as otherwise, the optimizer would only consider a category that has already been seen in the configurations history. For more details, please refer to the page of the reference guide.
Every RDS instance fetches the initialization parameters from the definition of the it is bound to. A best practice is to create a dedicated copy of the baseline group for the target database, in order to avoid impacting any other database that may share the same configuration object.
DB parameter groups must be configured through the the the dedicated . A simple way to implement this step in the Akamas workflow is to save the tested configuration in a configuration file and submit it through a custom executor leveraging the . The following snippets show an example tuning an instance with id oracletest, bound to configuration group named test-oracle:
To import the results of the benchmark into Akamas, we are going to use a custom script to convert its output to a CSV file that can be parsed by the .
We are going to use Akamas telemetry capability to import the metrics related to Sysbench benchmark results, in particular, the transaction throughput and latency. To achieve this we can leverage the Akamas , which extracts metrics from CSV files. The CSV file is the one produced in the last task of the workflow of the study.
As regards the workload generation, in this example we are going to use , a popular open-source benchmarking suite for databases. OLTPBench supports several benchmarks, in this example we will be using Synthetic Resource Stresser.
To import the results of the benchmark into Akamas, we are going to use a custom script to convert its output to a CSV file that can be parsed by the .
To install OLTP you can download a pre-built version or build it from the . In the following, we will assume that OLTP is installed in the /home/ubuntu/oltp folder.
We are going to use Akamas telemetry capability to import the metrics related to OLTPBench benchmark results, in particular the throughput of operations. To achieve this we can leverage the Akamas , which extracts metrics from CSV files. The CSV file is the one produced in the last task of the workflow of the study.
#!/bin/sh
cd "$(dirname "$0")" || exit
CACHESIZE=${mongo.mongodb_cache_size}
SYNCDELAY=${mongo.mongodb_syncdelay}
EVICTION_DIRTY_TRIGGER=${mongo.mongodb_eviction_dirty_trigger}
EVICTION_DIRTY_TARGET=${mongo.mongodb_eviction_dirty_target}
EVICTION_THREADS_MIN=${mongo.mongodb_eviction_threads_min}
EVICTION_THREADS_MAX=${mongo.mongodb_eviction_threads_max}
EVICTION_TRIGGER=${mongo.mongodb_eviction_trigger}
EVICTION_TARGET=${mongo.mongodb_eviction_target}
USE_NOATIME=${mongo.mongodb_datafs_use_noatime}
# Here we have to remount the disk mongodb uses for data, to take advantage of the USE_NOATIME parameter
sudo service mongod stop
sudo umount /mnt/mongodb
if [ "$USE_NOATIME" = true ]; then
sudo mount /dev/nvme0n1 /mnt/mongodb -o noatime
else
sudo mount /dev/nvme0n1 /mnt/mongodb
fi
sudo service mongod start
# flush logs
echo -n | sudo tee /mnt/mongodb/log/mongod.log
sudo service mongod restart
until grep -q "waiting for connections on port 27017" /mnt/mongodb/log/mongod.log
do
echo "waiting MongoDB..."
sleep 60
done
sleep 5
sudo service prometheus-mongodb-exporter restart
# set knobs
mongo --quiet --eval "db.adminCommand({setParameter:1, 'wiredTigerEngineRuntimeConfig': 'cache_size=${CACHESIZE}m, eviction=(threads_min=$EVICTION_THREADS_MIN,threads_max=$EVICTION_THREADS_MAX), eviction_dirty_trigger=$EVICTION_DIRTY_TRIGGER, eviction_dirty_target=$EVICTION_DIRTY_TARGET', eviction_trigger=$EVICTION_TRIGGER, eviction_target=$EVICTION_TARGET})"
mongo --quiet --eval "db = db.getSiblingDB('admin'); db.runCommand({ setParameter : 1, syncdelay: $SYNCDELAY})"
sleep 3Shell
#!/bin/bash
MONGODB_SERVER_IP="mongo.mycompany.com"
RECORDCOUNT=30000000
RUN_THREADS=10
LOAD_THREADS=10
DURATION=1800 # 30 minutes
WORKLOAD="a"
cd "$(dirname "$0")" || exit
# here we use the db_records file to check if we have already loaded the db with data
# if not we run a load script
db_records=$(cat db_records)
if [ "$RECORDCOUNT" != "$db_records" ]; then
bash scripts/create_db_mongo.sh ${MONGODB_SERVER_IP} "$RECORDCOUNT" "$LOAD_THREADS" "$WORKLOAD"
echo "$RECORDCOUNT" > db_records
fi
cd /home/myuser/ycsb-0.15.0 || exit
# launch task in background
./bin/ycsb run mongodb-async -s -P workloads/workload"$WORKLOAD" -threads "$RUN_THREADS" -p recordcount="$RECORDCOUNT" -p operationcount=0 -p maxexecutiontime="$DURATION" -p mongodb.url=mongodb://"$MONGODB_SERVER_IP":27017 &> /home/myuser/ycsb/outputRun.txt &
PID=$!
while kill -0 "$PID" >/dev/null 2>&1; do
echo running
if grep -q "java.net.ConnectException: Connection refused (Connection refused)" /home/myuser/ycsb/outputRun.txt; then
echo "No connection, killing time!"
echo -n > /home/myuser/ycsb/outputRun.txt
ps -ef | grep -i com.yahoo.ycsb.Client | awk '{print $2}' | xargs -I{} kill -9 {}
echo "Let's wait sometime... maybe Mongo is recovering data??"
sleep 900
exit 1
fi
if grep -Fxq "Could not create a connection to the server" /home/myuser/ycsb/outputRun.txt; then
echo "Unable to connect to server!"
kill -9 ${PID}
rm /home/myuser/ycsb/outputRun.txt
rm /home/myuser/ycsb/db_records
else
sleep 10
fi
done
name:sparkdescription:A system to tune the Spark Pi example application
name:sparkPidescription:The Spark Application used to calculate KPIs for ContentWise AnalyticscomponentType:Spark Application 2.3.0properties:hostname:sparkmaster.akamas.iousername:hadoopkey:ssh_keymaster:yarndeployMode:clientclassName:org.apache.spark.examples.SparkPifile:/usr/lib/spark/examples/jars/spark-examples.jarargs: [ 1000 ]sparkApplication:'true'
global:scrape_interval:15s# Set the scrape interval to every 15 seconds. The default is every 1 minute.evaluation_interval:15s# Evaluate rules every 15 seconds. The default is every 1 minute.scrape_timeout:15sscrape_configs:# Mongo exporter - job_name:'mongo_exporter'scrape_interval:15sstatic_configs: - targets: ['mongo.mycompany.com:9001']relabel_configs: - source_labels: ["__address__"]regex:".*"target_label:"instance"# this replacement should match the name of the akamas component of MongoDBreplacement:"mongo"
name:mongodb systemdescription:reference system
name:mongodescription:The MongoDB servercomponentType:MongoDB-4# MongoDB version 4properties:hostname:mongo.mycompany.comprometheus: # we are telling akamas that this component should be monitored using prometheus, and each data-point with a label instance=mongo should be mapped to this component
instance:mongosshPort:22username:myusernamekey:... RSA KEY ...
name:configure mongooperator:FileConfiguratorarguments: sourcePath: /home/myusername/mongo/templates/mongo_launcher.sh.templ # MongoDB configuration script with placeholders for Akamas parameters
targetPath:/home/myusername/mongo/launcher.sh# configuration script with interpolated Akamas parameterscomponent:mongo# mongo should match the component of your system that represents your MongoDB instance
name:launch mongooperator:Executorarguments:command:bash /home/myusername/mongo/launcher.shcomponent:mongo# we can take all the ssh connection parameters from the properties of the mongo component
name:launch ycsboperator:Executorarguments:command:bash /home/myusername/ycsb/launch_load.shcomponent:ycsb# we can take all the ssh connection parameters from the properties of the ycsb component
name:parse ycsb resultsoperator:Executorarguments:command:python /home/myusername/ycsb/parser.pycomponent:ycsb# we can take all the ssh connection parameters from the properties of the ycsb component
name:mongo workflowtasks: - name:configure mongooperator:FileConfiguratorarguments: sourcePath: /home/myusername/mongo/templates/mongo_launcher.sh.templ # MongoDB configuration script with placeholders for Akamas parameters
targetPath:/home/myusername/mongo/launcher.sh# configuration script with interpolated Akamas parameterscomponent:mongo# we can take all the ssh connection parameters from the properties of the mongo component - name:launch mongooperator:Executorarguments:command:bash /home/myusername/mongo/launcher.shcomponent:mongo# mongo should match the component of your system that represents your MongoDB instance - name:launch ycsboperator:Executorarguments:command:bash /home/myusername/ycsb/launch_load.shcomponent:ycsb# we can take all the ssh connection parameters from the properties of the ycsb component - name:parse ycsb resultsoperator:Executorarguments:command:python /home/myuser/ycsb/parser.pycomponent:ycsb# we can take all the ssh connection parameters from the properties of the ycsb component
provider:Prometheus# we are using Prometheusconfig:address:ycsb.mycompany.com# address of Prometheusport:9090metrics: - metric:mongodb_connections_currentdatasourceMetric:mongodb_connections{instance="$INSTANCE$"}labels: - state - metric:mongodb_heap_useddatasourceMetric:mongodb_extra_info_heap_usage_bytes{instance="$INSTANCE$"} - metric:mongodb_page_faults_totaldatasourceMetric:rate(mongodb_extra_info_page_faults_total{instance="$INSTANCE$"}[$DURATION$]) - metric:mongodb_global_lock_current_queuedatasourceMetric:mongodb_global_lock_current_queue{instance="$INSTANCE$"}labels: - type - metric:mongodb_mem_useddatasourceMetric:mongodb_memory{instance="$INSTANCE$"}labels: - type - metric:mongodb_documents_inserteddatasourceMetric:rate(mongodb_metrics_document_total{instance="$INSTANCE$", state="inserted"}[$DURATION$]) - metric:mongodb_documents_updateddatasourceMetric:rate(mongodb_metrics_document_total{instance="$INSTANCE$", state="updated"}[$DURATION$]) - metric:mongodb_documents_deleteddatasourceMetric:rate(mongodb_metrics_document_total{instance="$INSTANCE$", state="deleted"}[$DURATION$]) - metric:mongodb_documents_returneddatasourceMetric:rate(mongodb_metrics_document_total{instance="$INSTANCE$", state="returned"}[$DURATION$])
provider:CSVconfig:protocol:scpaddress:ycsb.mycompany.comusername:myuserauthType:keyauth:... RSA KEY ...remoteFilePattern:/home/ubuntu/ycsb/output.csvcsvFormat:horizontalcomponentColumn:ComponenttimestampColumn:timestamptimestampFormat:yyyy-MM-dd HH:mm:ssmetrics:# here we put which metric found in the csv provider should be mapped to which akamas metrics# we are only interested in the throughput, but you can add other metrics if you want - metric:throughputdatasourceMetric:throughput....
windowing:type:stabilitystability:# measure the goal function where the throughput has stdDev <= 200 for 100 consecutive data pointsmetric:throughputlabels:componentName:ycsbwidth:100maxStdDev:200# take only the temporal window when the throughput is maximumwhen:metric:throughputis:maxlabels:componentName:ycsb
parametersSelection: - name:mongo.mongodb_syncdelay - name:mongo.mongodb_eviction_dirty_trigger - name:mongo.mongodb_eviction_dirty_target - name:mongo.mongodb_eviction_target - name:mongo.mongodb_eviction_trigger - name:mongo.mongodb_eviction_threads_min - name:mongo.mongodb_eviction_threads_max - name:mongo.mongodb_cache_size # here we have changed the domain of the cache size since we suppose our mongo.mycompany.com host has 32gb of RAM, you should adapt to your own instance
domain: [500,32000]
steps:- name:baselinetype:baselinevalues:mongo.mongodb_cache_size:1024renderParameters:# use also all the other MongoDB parameters at their default value - mongo.*- name:optimize mongotype:optimizenumberOfExperiments:100
name:study to tune MongoDBdescription:study to tune MongoDB with YCSB perf testsystem:mongodb systemworkflow:mongo workflow# Goalgoal:objective:maximizefunction:formula:ycsb.throughput# Windowingwindowing:type:stabilitystability:metric:throughputlabels:componentName:ycsbwidth:100maxStdDev:200when:metric:throughputis:maxlabels:componentName:ycsb# parameters selectionparametersSelection: - name:mongo.mongodb_syncdelay - name:mongo.mongodb_eviction_dirty_trigger - name:mongo.mongodb_eviction_dirty_target - name:mongo.mongodb_eviction_target - name:mongo.mongodb_eviction_trigger - name:mongo.mongodb_eviction_threads_min - name:mongo.mongodb_eviction_threads_max - name:mongo.mongodb_cache_size# here we have changed the domain of the cache size since we suppose our mongo.mycompany.com host has 32gb of RAMdomain: [500,32000] - name:mongo.mongodb_datafs_use_noatimeparameterConstraints:- name:c1formula:mongo.mongodb_eviction_threads_min <= mongo.mongodb_eviction_threads_max- name:c2formula:mongodb_eviction_dirty_target <= mongodb_eviction_target- name:c3formula:mongodb_eviction_dirty_trigger <= mongodb_eviction_trigger# stepssteps:- name:baselinetype:baselinevalues:mongo.mongodb_cache_size:1024renderParameters:# use also all the other MongoDB parameters at their default value - mongo.*- name:optimize mongotype:optimizenumberOfExperiments:100
name:instancedescription:The ec2 instance the benchmark runs oncomponentType:ec2properties:hostname:renaissance.akamas.iosshPort:22instance:ec2_instanceusername:ubuntukey:# SSH KEYec2:region:us-east-2# This is just a reference
# Change instance type, requires AWS CLI- name:Resize the instancehosts:localhostgather_facts:noconnection:localtasks: - name:save instance infoec2_instance_info:filters:"tag:Name":<your-instance-name>register:ec2 - name:Stop the instanceec2:region:<your-aws-region>state:stoppedinstance_ids: - "{{ ec2.instances[0].instance_id }}"instance_type:"{{ ec2.instances[0].instance_type }}"wait:True - name:Change the instances ec2 typeshell:> aws ec2 modify-instance-attribute --instance-id "{{ ec2.instances[0].instance_id }}" --instance-type "${ec2.aws_ec2_instance_type}.${ec2.aws_ec2_instance_size}"delegate_to:localhost - name:restart the instanceec2:region:<your-aws-region>state:runninginstance_ids: - "{{ ec2.instances[0].instance_id }}"wait:Trueregister:ec2 - name:wait for SSH to come upwait_for:host:"{{ item.public_dns_name }}"port:22delay:60timeout:320state:startedwith_items:"{{ ec2.instances }}"
name:Pagerank AWS optimizationtasks:# Creating the EC2 instance - name:Configure provisioningoperator:FileConfiguratorarguments:sourcePath:/home/ubuntu/ansible/resize.yaml.templtargetPath:/home/ubuntu/ansible/resize.yamlhost:hostname:bastion.akamas.iousername:ubuntukey:# SSH KEY - name:Execute Provisioningoperator:Executorarguments:command:ansible-playbook /home/akamas/ansible/resize.yamlhost:hostname:bastion.akamas.iousername:akamaskey:# SSH KEY# Waiting for the instance to come up and set up its DNS - name:Pauseoperator:Sleeparguments:seconds:120# Running the benchmark - name:Configure Benchmarkoperator:FileConfiguratorarguments:source:hostname:renaissance.akamas.iousername:ubuntupath:/home/ubuntu/renaissance/launch_benchmark.sh.templkey:# SSH KEYtarget:hostname:renaissance.akamas.iousername:ubuntupath:/home/ubuntu/renaissance/launch_benchmark.shkey:# SSH KEY - name:Launch Benchmarkoperator:Executorarguments:command:bash /home/ubuntu/renaissance/launch_benchmark.shhost:hostname:renaissance.akamas.iousername:ubuntukey:# SSH KEYCreate the workflow resource by typing in your terminal:
# my global configglobal:scrape_interval:15s# Set the scrape interval to every 15 seconds. Default is every 1 minute.evaluation_interval:15s# Evaluate rules every 15 seconds. The default is every 1 minute.# A scrape configuration containing exactly one endpoint to scrape:# Here it's Prometheus itself.scrape_configs:# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name:prometheusstatic_configs: - targets: ['localhost:9090'] - job_name:jmxstatic_configs: - targets: ["localhost:9110"]relabel_configs: - source_labels: ["__address__"]regex:"(.*):.*"target_label:instancereplacement:jmx_instanc
startDelaySeconds:0username:password:ssl:falselowercaseOutputName:falselowercaseOutputLabelNames:false# using the property above we are telling the export to export only relevant java metricswhitelistObjectNames: - "java.lang:*" - "jvm:*"
[[metric]]context="memory"labels= [ "component" ]metricsdesc= { size="Component memory extracted from v$memory_dynamic_components in Oracle." }request ='''SELECT component, current_size as "size"FROM V$MEMORY_DYNAMIC_COMPONENTSUNIONSELECT name, bytes as "size"FROM V$SGAINFOWHERE name in ('Free SGA Memory Available', 'Redo Buffers', 'Maximum SGA Size')'''[[metric]]context ="activity"metricsdesc = { value="Generic counter metric from v$sysstat view in Oracle." }fieldtoappend ="name"request ='''SELECT name, valueFROM V$SYSSTAT WHERE name IN ( 'execute count', 'user commits', 'user rollbacks', 'db block gets from cache', 'consistent gets from cache', 'physical reads cache', /* CACHE */ 'redo log space requests' ) '''[[metric]]context ="system_event"labels = [ "event","wait_class" ]request ='''SELECT event, wait_class, total_waits, time_waitedFROM V$SYSTEM_EVENT'''[metric.metricsdesc] total_waits="Total number of waits for the event as per V$SYSTEM_EVENT in Oracle." time_waited="Total time waited for the event (in hundredths of seconds) as per V$SYSTEM_EVENT in Oracle."
name:oracle systemdescription:Multi-tier application model featuring Java technology and Oracle Database on cloud
name:oracledescription:Oracle DB for konakartcomponentType:Oracle Database 19cproperties:connection:user:userpassword:passwordhost:oradb.mycompany.comservice:konakartport:1521prometheus:instance:oradb
name:konakartdescription:Web application component for e2e metricscomponentType:Web Applicationproperties:prometheus:instance:jmeterjob:jmeter
#! /bin/bashnumOfKonakartRunning=$(psaux|grep"/opt/konakart/bin"|grep-v"grep"|wc-l)if [ $numOfKonakartRunning -eq0 ] ;thenecho"konakart not running"exit0elseecho"konakart is still running"exit1fi
#!/bin/bashORA_OWNER=oracleDB_NAME=kona_kartBAK_FILE=~/akamas/spfilekona.ora# [o] to avoid self-grepPMON=[o]ra_pmon_konaifps-ef|grep-q $PMON ; thenecho"[INFO] - Database running"elseifsudotest-f"$BAK_FILE"; thenecho"[INFO] - Trying to restore Oracle database using file $BAK_FILE"echo"[INFO] - ORACLE_HOME value is: $ORACLE_HOME"cp"$BAK_FILE""$ORACLE_HOME/dbs/"echo"[INFO] - Trying to restart oracle"echo"[INFO] - Stopping the database" $ORACLE_HOME/bin/dbshut $ORACLE_HOME# $ORACLE_HOME/bin/srvctl stop database -d $DB_NAMEcat $ORACLE_HOME/rdbms/log/shutdown.logecho"[INFO] - Starting the database" $ORACLE_HOME/bin/dbstart $ORACLE_HOME# $ORACLE_HOME/bin/srvctl start database -d $DB_NAMEcat $ORACLE_HOME/rdbms/log/startup.logps-ef|grep $PMONelseecho"[ERROR] - The spfile does not exist in current folder!"fiexit255fiexit0
#!/bin/bashORA_OWNER=oracleDB_NAME=kona_kart# [o] to avoid self-grepPMON=[o]ra_pmon_konaecho"[INFO] - Stopping the database"$ORACLE_HOME/bin/dbshut $ORACLE_HOME# $ORACLE_HOME/bin/srvctl stop database -d $DB_NAMEcat $ORACLE_HOME/rdbms/log/shutdown.logecho"[INFO] - Starting the database"$ORACLE_HOME/bin/dbstart $ORACLE_HOME# $ORACLE_HOME/bin/srvctl start database -d $DB_NAMEcat $ORACLE_HOME/rdbms/log/startup.logps-ef|grep $PMONexit0
- name:start konakartoperator:Executorarguments:retries:0command:/opt/konakart/bin/startkonakart.shhost:hostname:konakart.mycompany.comusername:ubuntukey:keyfile- name:wait for konakartoperator:Sleeparguments:retries:0seconds:30- name:check konakart service statusoperator:Executorarguments:retries:0command:bash /opt/scripts/check_konakart_start.shhost:hostname:konakart.mycompany.comusername:ubuntukey:keyfile
#! /bin/bashnumOfKonakartRunning=$(psaux|grep"/opt/konakart/bin"|grep-v"grep"|wc-l)if [ $numOfKonakartRunning -eq1 ] ;thenecho"konakart running"exit0elseecho"konakart not running"exit1fi
[[metric]]context="memory"labels= [ "component" ]metricsdesc= { size="Component memory extracted from v$memory_dynamic_components in Oracle." }request ='''SELECT component, current_size as "size"FROM V$MEMORY_DYNAMIC_COMPONENTSUNIONSELECT name, bytes as "size"FROM V$SGAINFOWHERE name in ('Free SGA Memory Available', 'Redo Buffers', 'Maximum SGA Size')'''[[metric]]context ="activity"metricsdesc = { value="Generic counter metric from v$sysstat view in Oracle." }fieldtoappend ="name"request ='''SELECT name, valueFROM V$SYSSTAT WHERE name IN ( 'execute count', 'user commits', 'user rollbacks', 'db block gets from cache', 'consistent gets from cache', 'physical reads cache', /* CACHE */ 'redo log space requests' ) '''[[metric]]context ="system_event"labels = [ "event","wait_class" ]request ='''SELECT event, wait_class, total_waits, time_waitedFROM V$SYSTEM_EVENT'''[metric.metricsdesc] total_waits="Total number of waits for the event as per V$SYSTEM_EVENT in Oracle." time_waited="Total time waited for the event (in hundredths of seconds) as per V$SYSTEM_EVENT in Oracle."
name:oracledescription:Oracle DBcomponentType:Oracle Database 18cproperties:instance:oraxeconnection:user:systempassword:passwddsn:oraxe.mycompany.com:1521/XEhostname:oraxe.mycompany.com# needed to run docker restartusername:ubuntusshPort:22key:rsa_key_file
name:containerdescription:Kubernetes container, part of the frontend deploymentcomponentType:Kubernetes Containerproperties:dynatrace:type:CONTAINER_GROUP_INSTANCEkubernetes:namespace:boutiquecontainerName:serverbasePodName:frontend-*
name:webappdescription:The service related to the frontend deploymentcomponentType:Web Applicationproperties:dynatrace:id:<TELEMETRY_DYNATRACE_WEBAPP_ID>
---metrics: - name:throughputdescription:The throughput of the databaseunit:tps - name:response_time_avgdescription:The average response time of the databaseunit:milliseconds - name:response_time_95thdescription:The response time 95th percentile of the databaseunit:milliseconds - name:durationdescription:The duration of the task (load or benchmark execution)unit:seconds
akamascreatemetricsmetrics.yaml
name:Sysbenchdescription:> Sysbench benchmark. It is a purely synthetic benchmark that can create isolated contention on system resources. Each of the benchmark’s transaction imposes some load on three specific resources: CPU, disk I/O, and locks. It is also used to simulate a database workload.
parameters: []metrics: - name:throughput - name:response_time_avg - name:response_time_95th - name:duration
name:MySQL-Sysbenchdescription:A system for optimizing MySQL with Sysbench
name:Sysbenchdescription:Sysbench Benchmark for database systemscomponentType:Sysbench
#!/usr/bin/env bashset-ecd"$(dirname "$0")"#Stop the DBecho"Stopping MySQL"sudosystemctlstopmysql&> /dev/null#sudo systemctl status mysql#Apply Configurationecho"Copying the configuration"sudocpmy.cnf/etc/mysql/conf.d/mysql.cnfsync; sudosh-c"echo 3 > /proc/sys/vm/drop_caches"; sync#Restart DBecho"Restarting the database"sudosystemctlstartmysql&> /dev/null#sudo systemctl status mysqlsleep2
name:MySQL Sysbench Tuningdescription:Tuning of mysql-8 with Sysbench benchmarksystem:MySQL-Sysbenchworkflow:MySQL-Sysbenchgoal:objective:maximizefunction:formula:Sysbench.throughputconstraints: []# Akamas score automatically trim 1m of warm-up and 1m of tear-downwindowing:task:testtype:trimtrim: [1m,1m]# We optimize some common MySQL parametersparametersSelection: - name:mysql.mysql_innodb_buffer_pool_sizedomain: [5242880,10485760] - name:mysql.mysql_innodb_thread_sleep_delaydomain: [1,3000] - name:mysql.mysql_innodb_flush_method - name:mysql.mysql_innodb_log_file_size - name:mysql.mysql_innodb_thread_concurrencydomain: [0,4] - name:mysql.mysql_innodb_max_dirty_pages_pct - name:mysql.mysql_innodb_read_ahead_threshold# The metrics we are interested inmetricsSelection: - Sysbench.throughput - Sysbench.response_time_95th# Each experiment can run multiple trials to evaluate stabilitynumberOfTrials:1steps:# We first run a baseline experiment with default values - name:baselinetype:baselinerenderParameters: ["mysql.*"]# We then optimize for 200 experiments - name:optimizetype:optimizeoptimizer:AKAMASnumberOfExperiments:200maxFailedExperiments:200renderParameters: ["mysql.*"]
#!/bin/bashset-ecd"$(dirname "$0")"cd../oltpmysql-uroot-proot-e"CREATE DATABASE resourcestresser"./oltpbenchmark--benchresourcestresser--configscripts/resourcestresser.xml--create=true--load=truesleep5sudosystemctlstopmysql#Create the backupecho"Backing up the database"sudorm-rf/tmp/backupsudomkdir/tmp/backupsudorsync-r--progress/var/lib/mysql/tmp/backup/sleep2sudosystemctlstartmysqlsudosystemctlstatusmysql
---metrics: - name:throughputdescription:The throughput of the databaseunit:tps - name:response_time_avgdescription:The average response time of the databaseunit:milliseconds - name:response_time_mindescription:The minimum response time of the databaseunit:milliseconds - name:response_time_25thdescription:The response time 25th percentile of the databaseunit:milliseconds - name:response_time_mediandescription:The response time median of the databaseunit:milliseconds - name:response_time_75thdescription:The response time 75th percentile of the databaseunit:milliseconds - name:response_time_90thdescription:The response time 90th percentile of the databaseunit:milliseconds - name:response_time_95thdescription:The response time 95th percentile of the databaseunit:milliseconds - name:response_time_99thdescription:The response time 99th percentile of the databaseunit:milliseconds - name:response_time_maxdescription:The maximum response time of the databaseunit:milliseconds - name:durationdescription:The duration of the task (load or benchmark execution)unit:seconds
akamascreatemetricsmetrics.yaml
name:ResourceStresserdescription:> ResourceStresser benchmark from OLTPBench for database systems. It is a purely synthetic benchmark that can create isolated contention on the system resources. Each of the benchmark’s transactions imposes some load on three specific resources: CPU, disk I/O, and locks.parameters: []metrics: - name:throughput - name:response_time_avg - name:response_time_max - name:response_time_min - name:response_time_25th - name:response_time_median - name:response_time_75th - name:response_time_90th - name:response_time_95th - name:response_time_99th - name:duration
akamascreatecomponent-typeresourcestresser.yaml
name:MySQL-ResourceStresserdescription:A system for evaluating MySQL with OLTP Benchmark
#!/usr/bin/env bashset-ecd"$(dirname "$0")"#Stop the DBecho"Stopping MySQL"sudosystemctlstopmysql&> /dev/null#sudo systemctl status mysql#Apply Configurationecho"Copying the configuration"sudocpmy.cnf/etc/mysql/conf.d/mysql.cnf#Drop dataecho"Dropping the data"sudorm-rf/var/lib/mysql#Create the backup# sudo rsync -r --progress /var/lib/mysql /tmp/backup/#Restore the backup dataecho"Restoring the DB"sudorsync-r--progress/tmp/backup/mysql/var/lib/sudochown-Rmysql:/var/lib/mysqlsync; sudosh-c"echo 3 > /proc/sys/vm/drop_caches"; sync#Restart DBecho"Restarting the database"sudosystemctlstartmysql&> /dev/null#sudo systemctl status mysqlsleep2