-
-
-
-redirecting to newest documentation... Click here if nothing happens.
-
-
\ No newline at end of file
diff --git a/.github/pages/latest.html b/.github/pages/latest.html
deleted file mode 100644
index cfb2e03bd..000000000
--- a/.github/pages/latest.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
-
-
-
-
-redirecting to newest documentation... Click here if nothing happens.
-
-
\ No newline at end of file
diff --git a/.github/workflows/lint.yml b/.github/workflows/check_version.yml
similarity index 68%
rename from .github/workflows/lint.yml
rename to .github/workflows/check_version.yml
index b93711e40..770bf137c 100644
--- a/.github/workflows/lint.yml
+++ b/.github/workflows/check_version.yml
@@ -1,4 +1,5 @@
-name: lint
+# Checks if version number has been updated
+name: Version Check
on: pull_request
jobs:
@@ -6,5 +7,5 @@ jobs:
name: Release Tag existence Check
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@main
+ - uses: actions/checkout@v3
- run: .github/scripts/tagcheck.sh v$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)
\ No newline at end of file
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
deleted file mode 100644
index 0da84be32..000000000
--- a/.github/workflows/ci.yml
+++ /dev/null
@@ -1,99 +0,0 @@
-name: ci
-on:
- push:
- branches:
- - main
-jobs:
- deploy:
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v2
- - name: Set up JDK 11
- uses: actions/setup-java@v2
- with:
- java-version: '11'
- distribution: 'adopt'
- - name: Cache Maven packages
- uses: actions/cache@v2
- with:
- path: ~/.m2
- key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
- restore-keys: ${{ runner.os }}-m2
- - uses: actions/setup-python@v2
- with:
- python-version: 3.x
- - shell: bash
- run: mvn help:evaluate -Dexpression=major.minor.version -q -DforceStdout > version.log
- - shell: bash
- run: mvn help:evaluate -Dexpression=project.artifactId -q -DforceStdout > artifactid.log
- - name: Set env version
- run: echo "MM_VERSION=$(cat version.log)" >> $GITHUB_ENV
- - name: Set env version
- run: echo "RELEASE_VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)" >> $GITHUB_ENV
- - name: Set env name
- run: echo "RELEASE_ARTIFACTID=$(cat artifactid.log)" >> $GITHUB_ENV
- - name: test
- run: echo ${{ env.RELEASE_VERSION }} ${{ env.RELEASE_ARTIFACTID }}
- - run: pip install mkdocs-material
- - run: pip install mkdocs-macros-plugin
- - run: sed -i "s/\$VERSION/$(cat version.log)/g" mkdocs.yml
- - run: sed -i "s/\$RELEASE_VERSION/${{ env.RELEASE_VERSION }}/g" mkdocs.yml
- - run: mkdocs build -d site/$(cat version.log)
- - run: mvn install -Dmaven.test.skip=true
- - run: mvn javadoc:javadoc
- - run: sed -i "s/\$VERSION/$(cat version.log)/g" .github/pages/latest.html
- - run: sed -i "s/\$VERSION/$(cat version.log)/g" .github/pages/javadoc-latest.html
- - name: Deploy Site
- uses: peaceiris/actions-gh-pages@v3
- with:
- github_token: ${{ secrets.GITHUB_TOKEN }}
- publish_dir: ./site/${{ env.MM_VERSION }}
- destination_dir: ./docs/${{ env.MM_VERSION }}
- - name: Deploy Javadoc
- uses: peaceiris/actions-gh-pages@v3
- with:
- github_token: ${{ secrets.GITHUB_TOKEN }}
- publish_dir: ./javadoc/${{ env.MM_VERSION }}
- destination_dir: ./javadoc/${{ env.MM_VERSION }}
- - name: Deploy latest.html
- uses: peaceiris/actions-gh-pages@v3
- with:
- github_token: ${{ secrets.GITHUB_TOKEN }}
- publish_dir: .github/pages/
- keep_files: true
- destination_dir: ./docs/
- - name: Deploy latest.html
- uses: peaceiris/actions-gh-pages@v3
- with:
- github_token: ${{ secrets.GITHUB_TOKEN }}
- publish_dir: .github/pages/
- keep_files: true
- destination_dir: ./docs/
- - run: mkdir iguana
- - run: cp target/start-iguana.sh iguana/
- - run: cp target/iguana-${{ env.RELEASE_VERSION }}.jar iguana/iguana-${{ env.RELEASE_VERSION }}.jar
- - run: cp example-suite.yml iguana/
- - run: zip -r iguana-${{ env.RELEASE_VERSION }}.zip iguana/
- - name: Create Release
- id: create_release
- uses: actions/create-release@v1
- env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- with:
- tag_name: v${{ env.RELEASE_VERSION }}
- release_name: version ${{ env.RELEASE_VERSION }}
- draft: false
- prerelease: false
- body: ""
- - uses: actions/upload-release-asset@v1.0.1
- env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- with:
- upload_url: ${{ steps.create_release.outputs.upload_url }}
- asset_path: iguana-${{ env.RELEASE_VERSION }}.zip
- asset_name: iguana-${{ env.RELEASE_VERSION }}.zip
- asset_content_type: application/zip
- - name: Publish package
- run: mvn --batch-mode deploy -Dmaven.test.skip=true
- env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
\ No newline at end of file
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
new file mode 100644
index 000000000..52f1e6b13
--- /dev/null
+++ b/.github/workflows/deploy.yml
@@ -0,0 +1,174 @@
+name: Deployment
+
+on:
+ push:
+ branches:
+ - main
+
+jobs:
+ find_version:
+ name: Find Release Version
+ runs-on: ubuntu-latest
+ outputs:
+ RELEASE_VERSION: ${{ steps.step_find.outputs.RELEASE_VERSION }}
+ steps:
+ - uses: actions/checkout@v4
+ - uses: actions/setup-java@v3
+ with:
+ java-version: '17'
+ distribution: 'adopt'
+ cache: 'maven'
+ - name: 'Find velease version'
+ run: echo "RELEASE_VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)" >> $GITHUB_OUTPUT
+ id: step_find
+
+ deploy_to_maven:
+ name: Deploy to Maven Repository
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v4
+ - name: Set up JDK 17
+ uses: actions/setup-java@v3
+ with:
+ java-version: '17'
+ distribution: 'adopt'
+ cache: 'maven'
+ - name: Publish package
+ run: mvn --batch-mode deploy -Dmaven.test.skip=true
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ - name: 'Upload artifact'
+ uses: actions/upload-artifact@v4
+ with:
+ if-no-files-found: error
+ name: 'iguana-jar'
+ path: 'target/'
+
+
+ compile_native:
+ name: Compile Native Executable
+ runs-on: ubuntu-latest
+ needs: find_version
+ steps:
+ - uses: actions/checkout@v4
+ - name: Set up GraalVM
+ uses: graalvm/setup-graalvm@v1
+ with:
+ java-version: 22
+ components: native-image
+ cache: maven
+ - name: 'Compile native-binary'
+ run: 'mvn -Dagent=true -Pnative package'
+ - name: 'Upload artifact'
+ uses: actions/upload-artifact@v4
+ with:
+ name: 'iguana-native'
+ path: 'target/iguana'
+ if-no-files-found: error
+
+ deploy_docs:
+ name: Deploy Documentation
+ runs-on: ubuntu-latest
+ needs: find_version
+ env:
+ RELEASE_VERSION: ${{ needs.find_version.outputs.RELEASE_VERSION }}
+ steps:
+ - uses: actions/checkout@v4
+ - name: Set up JDK 17
+ uses: actions/setup-java@v3
+ with:
+ java-version: '17'
+ distribution: 'adopt'
+ cache: 'maven'
+ - name: Set up Python
+ uses: actions/setup-python@v5
+ with:
+ python-version: 3.x
+ - run: pip install mkdocs-material
+ - run: pip install mkdocs-macros-plugin
+ - run: sed -i "s/\$RELEASE_VERSION/${{ env.RELEASE_VERSION }}/g" mkdocs.yml
+
+ - run: mkdocs build -d site/${{ env.RELEASE_VERSION }}
+ - run: mvn javadoc:javadoc
+
+ - name: Deploy Site
+ uses: peaceiris/actions-gh-pages@v3
+ with:
+ github_token: ${{ secrets.GITHUB_TOKEN }}
+ publish_dir: ./site/${{ env.RELEASE_VERSION }}
+ destination_dir: ./docs/${{ env.RELEASE_VERSION }}
+ - name: Deploy Site
+ uses: peaceiris/actions-gh-pages@v3
+ with:
+ github_token: ${{ secrets.GITHUB_TOKEN }}
+ publish_dir: ./site/${{ env.RELEASE_VERSION }}
+ destination_dir: ./docs/latest
+
+ - name: Deploy Javadoc
+ uses: peaceiris/actions-gh-pages@v3
+ with:
+ github_token: ${{ secrets.GITHUB_TOKEN }}
+ publish_dir: ./javadoc/${{ env.RELEASE_VERSION }}/apidocs
+ destination_dir: ./javadoc/${{ env.RELEASE_VERSION }}
+ - name: Deploy Javadoc
+ uses: peaceiris/actions-gh-pages@v3
+ with:
+ github_token: ${{ secrets.GITHUB_TOKEN }}
+ publish_dir: ./javadoc/${{ env.RELEASE_VERSION }}/apidocs
+ destination_dir: ./javadoc/latest
+
+ - name: Find Ontology Version
+ run: echo "ONTOLOGY_VERSION=$(grep 'versionIRI' schema/iguana.owx | grep -Po '[0-9]+.[0-9]+.[0-9]+')" >> $GITHUB_OUTPUT
+ id: find_ontology_version
+
+ - name: Fetch Ontologies
+ run: git fetch && git checkout origin/gh-pages ontology/
+ - run: mkdir -p ontology/${{ steps.find_ontology_version.outputs.ONTOLOGY_VERSION }}
+ - run: cp schema/iguana.owx ontology/${{ steps.find_ontology_version.outputs.ONTOLOGY_VERSION }}/iguana.owx
+ - run: cp schema/iguana.owx ontology/iguana.owx
+
+ - name: Deploy Ontology
+ uses: peaceiris/actions-gh-pages@v3
+ with:
+ github_token: ${{ secrets.GITHUB_TOKEN }}
+ publish_dir: ./ontology/
+ destination_dir: ./ontology/
+
+
+ deploy_gh_release:
+ name: Publish GitHub Release
+ runs-on: ubuntu-latest
+ needs: [compile_native, deploy_to_maven, find_version]
+ env:
+ RELEASE_VERSION: ${{ needs.find_version.outputs.RELEASE_VERSION }}
+
+ steps:
+ - uses: actions/checkout@v4
+ - name: Download artifacts from previous jobs
+ uses: actions/download-artifact@v4
+ with:
+ path: artifacts/
+ merge-multiple: true
+ - name: Prepare files
+ run: |
+ mkdir iguana
+ cp artifacts/start-iguana.sh iguana/
+ cp artifacts/iguana.jar iguana/iguana.jar
+ cp artifacts/iguana iguana/iguana
+ cp example-suite.yml iguana/
+ zip -r iguana-${{ env.RELEASE_VERSION }}.zip iguana/
+ - name: Create Release
+ uses: softprops/action-gh-release@v2
+ with:
+ tag_name: v${{ env.RELEASE_VERSION }}
+ name: version ${{ env.RELEASE_VERSION }}
+ draft: false
+ prerelease: false
+ body: ""
+ fail_on_unmatched_files: true
+ make_latest: true
+ token: ${{ secrets.GITHUB_TOKEN }}
+ files: |
+ iguana-${{ env.RELEASE_VERSION }}.zip
+ artifacts/iguana.jar
+ artifacts/iguana
diff --git a/.github/workflows/maven.yml b/.github/workflows/maven.yml
deleted file mode 100644
index 9d5b56ab7..000000000
--- a/.github/workflows/maven.yml
+++ /dev/null
@@ -1,23 +0,0 @@
-name: testing
-on:
- push:
- branches:
- - develop
-jobs:
- deploy:
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v2
- - name: Set up JDK 11
- uses: actions/setup-java@v2
- with:
- java-version: '11'
- distribution: 'adopt'
- - name: Cache Maven packages
- uses: actions/cache@v2
- with:
- path: ~/.m2
- key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
- restore-keys: ${{ runner.os }}-m2
- - name: Testing the Java code
- run: mvn install
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
new file mode 100644
index 000000000..3931192b6
--- /dev/null
+++ b/.github/workflows/tests.yml
@@ -0,0 +1,55 @@
+name: Tests
+
+concurrency:
+ group: ${{ github.workflow }}-${{ github.ref }}
+ cancel-in-progress: true
+
+on:
+ push:
+ branches:
+ - develop
+ pull_request:
+ branches:
+ - develop
+ - main
+
+jobs:
+ tests:
+ name: Compile and Run Tests
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v3
+ - name: Set up JDK 17
+ uses: actions/setup-java@v3
+ with:
+ java-version: '17'
+ distribution: 'adopt'
+ - name: Cache Maven packages
+ uses: actions/cache@v2
+ with:
+ path: ~/.m2
+ key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
+ restore-keys: ${{ runner.os }}-m2
+ - name: Testing the Java code
+ run: mvn package
+
+ # Only run for pull request on main or if pushed to develop
+ compile_native:
+ name: Test Native Executable Compilation
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v4
+ - name: Set up GraalVM
+ uses: graalvm/setup-graalvm@v1
+ with:
+ java-version: 22
+ components: native-image
+ cache: maven
+ - name: 'Compile native-binary and run tests'
+ run: 'mvn -Pnative -Dagent=true package'
+ - name: 'Upload artifact'
+ uses: actions/upload-artifact@v4
+ with:
+ name: 'iguana-native'
+ path: 'target/iguana'
+ if-no-files-found: error
diff --git a/.gitignore b/.gitignore
index dfd0dc545..bc02395e7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,8 +5,8 @@ tmp_ser
**/queryInstances/*
-# Created by https://www.toptal.com/developers/gitignore/api/java,maven,intellij,eclipse
-# Edit at https://www.toptal.com/developers/gitignore?templates=java,maven,intellij,eclipse
+# Created by https://www.toptal.com/developers/gitignore/api/java,maven,intellij+all,eclipse
+# Edit at https://www.toptal.com/developers/gitignore?templates=java,maven,intellij+all,eclipse
### Eclipse ###
.metadata
@@ -74,7 +74,7 @@ local.properties
# Spring Boot Tooling
.sts4-cache/
-### Intellij ###
+### Intellij+all ###
# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider
# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839
@@ -153,39 +153,14 @@ fabric.properties
# Android studio 3.1+ serialized cache file
.idea/caches/build_file_checksums.ser
-### Intellij Patch ###
-# Comment Reason: https://github.com/joeblau/gitignore.io/issues/186#issuecomment-215987721
+### Intellij+all Patch ###
+# Ignore everything but code style settings and run configurations
+# that are supposed to be shared within teams.
-# *.iml
-# modules.xml
-# .idea/misc.xml
-# *.ipr
-
-# Sonarlint plugin
-# https://plugins.jetbrains.com/plugin/7973-sonarlint
-.idea/**/sonarlint/
-
-# SonarQube Plugin
-# https://plugins.jetbrains.com/plugin/7238-sonarqube-community-plugin
-.idea/**/sonarIssues.xml
-
-# Markdown Navigator plugin
-# https://plugins.jetbrains.com/plugin/7896-markdown-navigator-enhanced
-.idea/**/markdown-navigator.xml
-.idea/**/markdown-navigator-enh.xml
-.idea/**/markdown-navigator/
+.idea/*
-# Cache file creation bug
-# See https://youtrack.jetbrains.com/issue/JBR-2257
-.idea/$CACHE_FILE$
-
-# CodeStream plugin
-# https://plugins.jetbrains.com/plugin/12206-codestream
-.idea/codestream.xml
-
-# Azure Toolkit for IntelliJ plugin
-# https://plugins.jetbrains.com/plugin/8053-azure-toolkit-for-intellij
-.idea/**/azureSettings.xml
+!.idea/codeStyles
+!.idea/runConfigurations
### Java ###
# Compiled class file
@@ -232,6 +207,4 @@ buildNumber.properties
# JDT-specific (Eclipse Java Development Tools)
.classpath
-# End of https://www.toptal.com/developers/gitignore/api/java,maven,intellij,eclipse
-
-
+# End of https://www.toptal.com/developers/gitignore/api/java,maven,intellij+all,eclipse
diff --git a/README.md b/README.md
deleted file mode 100644
index 1b8c5f00f..000000000
--- a/README.md
+++ /dev/null
@@ -1,148 +0,0 @@
-[![GitLicense](https://gitlicense.com/badge/dice-group/IGUANA)](https://gitlicense.com/license/dice-group/IGUANA)
-![Java CI with Maven](https://github.com/dice-group/IGUANA/workflows/Java%20CI%20with%20Maven/badge.svg)[![BCH compliance](https://bettercodehub.com/edge/badge/AKSW/IGUANA?branch=master)](https://bettercodehub.com/)
-[![Codacy Badge](https://api.codacy.com/project/badge/Grade/9668460dd04c411fab8bf5ee9c161124)](https://www.codacy.com/app/TortugaAttack/IGUANA?utm_source=github.com&utm_medium=referral&utm_content=AKSW/IGUANA&utm_campaign=Badge_Grade)
-[![Project Stats](https://www.openhub.net/p/iguana-benchmark/widgets/project_thin_badge.gif)](https://www.openhub.net/p/iguana-benchmark)
-
-
-# IGUANA
-
-
-
-## ABOUT
-
-
-Semantic Web is becoming more important and it's data is growing each day. Triple stores are the backbone here, managing these data.
-Hence it is very important that the triple store must scale on the data and can handle several users.
-Current Benchmark approaches could not provide a realistic scenario on realistic data and could not be adjustet for your needs very easily.
-Additionally Question Answering systems and Natural Language Processing systems are becoming more and more popular and thus needs to be stresstested as well.
-Further on it was impossible to compare results for different benchmarks.
-
-Iguana is an an Integerated suite for benchmarking read/write performance of HTTP endpoints and CLI Applications. which solves all these issues.
-It provides an enviroment which ...
-
-
-+ ... is highly configurable
-+ ... provides a realistic scneario benchmark
-+ ... works on every dataset
-+ ... works on SPARQL HTTP endpoints
-+ ... works on HTTP Get & Post endpoints
-+ ... works on CLI applications
-+ and is easily extendable
-
-
-For further Information visit
-
-[iguana-benchmark.eu](http://iguana-benchmark.eu)
-
-[Documentation](http://iguana-benchmark.eu/docs/3.3/)
-
-
-# Getting Started
-
-# Prerequisites
-
-You need to install Java 11 or greater.
-In Ubuntu you can install these using the following commands
-
-```
-sudo apt-get install java
-```
-
-# Iguana Modules
-
-Iguana consists of two modules
-
-1. **corecontroller**: This will benchmark the systems
-2. **resultprocessor**: This will calculate the Metrics and save the raw benchmark results
-
-## **corecontroller**
-
-The **corecontroller** will benchmark your system. It should be started on the same machine the is started.
-
-## **resultprocessor**
-
-The **resultprocessor** will calculate the metrics.
-By default it stores its result in a ntriple file. But you may configure it, to write the results directly to a Triple Store.
-On the processing side, it calculates various metrics.
-
-Per run metrics:
-* Query Mixes Per Hour (QMPH)
-* Number of Queries Per Hour (NoQPH)
-* Number of Queries (NoQ)
-* Average Queries Per Second (AvgQPS)
-
-Per query metrics:
-* Queries Per Second (QPS)
- * Number of successful and failed queries
- * result size
- * queries per second
- * sum of execution times
-
-You can change these in the Iguana Benchmark suite config.
-
-If you use the [basic configuration](https://github.com/dice-group/IGUANA/blob/master/example-suite.yml), it will save all mentioned metrics to a file called `results_{{DATE_RP_STARTED}}.nt`
-
-
-# Setup Iguana
-
-## Download
-Please download the release zip **iguana-x.y.z.zip** from the newest release available [here](https://github.com/dice-group/IGUANA/releases/latest):
-
-```
-mkdir iguana
-wget https://github.com/dice-group/IGUANA/releases/download/v3.3.2/iguana-3.3.2.zip
-unzip iguana-3.3.2.zip
-```
-
-
-It contains the following files:
-
-* iguana.corecontroller-X.Y.Z.jar
-* start-iguana.sh
-* example-suite.yml
-
-# Run Your Benchmarks
-
-## Create a Configuration
-
-You can use the [basic configuration](https://github.com/dice-group/IGUANA/blob/master/example-suite.yml) we provide and modify it to your needs.
-For further information please visit our [configuration](http://iguana-benchmark.eu/docs/3.2/usage/configuration/) and [Stresstest](http://iguana-benchmark.eu/docs/3.0/usage/stresstest/) wiki pages. For a detailed, step-by-step instruction please attend our [tutorial](http://iguana-benchmark.eu/docs/3.2/usage/tutorial/).
-
-
-
-## Execute the Benchmark
-
-Use the start script
-```
-./start-iguana.sh example-suite.yml
-```
-Now Iguana will execute the example benchmark suite configured in the example-suite.yml file
-
-
-# How to Cite
-
-```bibtex
-@InProceedings{10.1007/978-3-319-68204-4_5,
-author="Conrads, Lixi
-and Lehmann, Jens
-and Saleem, Muhammad
-and Morsey, Mohamed
-and Ngonga Ngomo, Axel-Cyrille",
-editor="d'Amato, Claudia
-and Fernandez, Miriam
-and Tamma, Valentina
-and Lecue, Freddy
-and Cudr{\'e}-Mauroux, Philippe
-and Sequeda, Juan
-and Lange, Christoph
-and Heflin, Jeff",
-title="Iguana: A Generic Framework for Benchmarking the Read-Write Performance of Triple Stores",
-booktitle="The Semantic Web -- ISWC 2017",
-year="2017",
-publisher="Springer International Publishing",
-address="Cham",
-pages="48--65",
-abstract="The performance of triples stores is crucial for applications driven by RDF. Several benchmarks have been proposed that assess the performance of triple stores. However, no integrated benchmark-independent execution framework for these benchmarks has yet been provided. We propose a novel SPARQL benchmark execution framework called Iguana. Our framework complements benchmarks by providing an execution environment which can measure the performance of triple stores during data loading, data updates as well as under different loads and parallel requests. Moreover, it allows a uniform comparison of results on different benchmarks. We execute the FEASIBLE and DBPSB benchmarks using the Iguana framework and measure the performance of popular triple stores under updates and parallel user requests. We compare our results (See https://doi.org/10.6084/m9.figshare.c.3767501.v1) with state-of-the-art benchmarking results and show that our benchmark execution framework can unveil new insights pertaining to the performance of triple stores.",
-isbn="978-3-319-68204-4"
-}
-```
diff --git a/README.md b/README.md
new file mode 120000
index 000000000..0e01b4308
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+docs/README.md
\ No newline at end of file
diff --git a/customs/images/Iguana_new_logo6.png b/customs/images/Iguana_new_logo6.png
deleted file mode 100644
index 988f32f4c..000000000
Binary files a/customs/images/Iguana_new_logo6.png and /dev/null differ
diff --git a/customs/images/iguana-result-schema.png b/customs/images/iguana-result-schema.png
deleted file mode 100644
index 2781fcace..000000000
Binary files a/customs/images/iguana-result-schema.png and /dev/null differ
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 000000000..afc6d7e05
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,107 @@
+
+
+
+
+# IGUANA
+Iguana is a benchmarking framework for testing the read performances of HTTP endpoints.
+It is mostly designed for benchmarking triplestores by using the SPARQL protocol.
+Iguana stresstests endpoints by simulating users which send a set of queries independently of each other.
+
+Benchmarks are configured using a YAML-file, this allows them to be easily repeated and adjustable.
+Results are stored in RDF-files and can also be exported as CSV-files.
+
+## Features
+- Benchmarking of (SPARQL) HTTP endpoints
+- Reusable configuration
+- Calculation of various metrics for better comparisons
+- Processing of HTTP responses (e.g., results counting)
+
+## Setup
+
+### Prerequisites
+
+If you're using the native version of IGUANA, you need to have at least a `x86-64-v3` (Intel Haswell and AMD Excavator or newer) system that is running Linux.
+
+If you're using the Java version of IGUANA, you need to have `Java 17` or higher installed.
+On Ubuntu it can be installed by executing the following command:
+
+```bash
+sudo apt install openjdk-17-jre
+```
+
+### Download
+The latest release can be downloaded at https://github.com/dice-group/IGUANA/releases/latest.
+The zip file contains three files:
+
+* `iguana`
+* `iguana.jar`
+* `example-suite.yml`
+* `start-iguana.sh`
+
+The `iguana` file is a native executable for IGUANA that has been compiled with GraalVM.
+The `iguana.jar` file is the standard Java executable for IGUANA.
+The `start-iguana.sh` script is a helper script to start IGUANA with the `iguana.jar` file.
+
+### Configuration
+The `example-suite.yml` file contains an extensive configuration for a benchmark suite.
+It can be used as a starting point for your own benchmark suite.
+For a detailed explanation of the configuration, see the [configuration](./configuration/overview.md) documentation.
+
+## Usage
+
+### Native Version
+
+Start Iguana with a benchmark suite (e.g., the `example-suite.yml`) by executing the binary:
+
+```bash
+./iguana example-suite.yml
+```
+
+### Java Version
+
+Start Iguana with a benchmark suite (e.g., the `example-suite.yml`) either by using the start script:
+
+```bash
+./start-iguana.sh example-suite.yml
+```
+
+or by directly executing the jar-file:
+
+```bash
+java -jar iguana.jar example-suite.yml
+```
+
+If you're using the script, you can use JVM arguments by setting the environment variable `IGUANA_JVM`.
+For example, to let Iguana use 4GB of RAM you can set `IGUANA_JVM` as follows:
+
+```bash
+export IGUANA_JVM=-Xmx4g
+```
+
+# How to Cite
+
+```bibtex
+@InProceedings{10.1007/978-3-319-68204-4_5,
+author="Conrads, Lixi
+and Lehmann, Jens
+and Saleem, Muhammad
+and Morsey, Mohamed
+and Ngonga Ngomo, Axel-Cyrille",
+editor="d'Amato, Claudia
+and Fernandez, Miriam
+and Tamma, Valentina
+and Lecue, Freddy
+and Cudr{\'e}-Mauroux, Philippe
+and Sequeda, Juan
+and Lange, Christoph
+and Heflin, Jeff",
+title="Iguana: A Generic Framework for Benchmarking the Read-Write Performance of Triple Stores",
+booktitle="The Semantic Web -- ISWC 2017",
+year="2017",
+publisher="Springer International Publishing",
+address="Cham",
+pages="48--65",
+abstract="The performance of triples stores is crucial for applications driven by RDF. Several benchmarks have been proposed that assess the performance of triple stores. However, no integrated benchmark-independent execution framework for these benchmarks has yet been provided. We propose a novel SPARQL benchmark execution framework called Iguana. Our framework complements benchmarks by providing an execution environment which can measure the performance of triple stores during data loading, data updates as well as under different loads and parallel requests. Moreover, it allows a uniform comparison of results on different benchmarks. We execute the FEASIBLE and DBPSB benchmarks using the Iguana framework and measure the performance of popular triple stores under updates and parallel user requests. We compare our results (See https://doi.org/10.6084/m9.figshare.c.3767501.v1) with state-of-the-art benchmarking results and show that our benchmark execution framework can unveil new insights pertaining to the performance of triple stores.",
+isbn="978-3-319-68204-4"
+}
+```
\ No newline at end of file
diff --git a/docs/about.md b/docs/about.md
deleted file mode 100644
index 37e2a0ccc..000000000
--- a/docs/about.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Iguana
-Iguana is an an Integerated suite for benchmarking read/write performance of HTTP endpoints and CLI Applications.
-Semantic Web is becoming more important and it's data is growing each day. Triple stores are the backbone here, managing these data. Hence it is very important that the triple store must scale on the data and can handle several users. Current Benchmark approaches could not provide a realistic scenario on realistic data and could not be adjustet for your needs very easily. Additionally Question Answering systems and Natural Language Processing systems are becoming more and more popular and thus needs to be stresstested as well. Further on it was impossible to compare results for different benchmarks.
-
-Iguana tries to solve all these issues. It provides an enviroment which ...
-
-* is highly configurable
-* provides a realistic scneario benchmark
-* works on every dataset
-* works on SPARQL HTTP endpoints
-* works on HTTP Get & Post endpoints
-* works on CLI applications
-* and is easily extendable
-
-## What is Iguana
-
-Iguana is a HTTP and CLI read/write performance benchmark framework suite.
-It can stresstest HTTP get and post endpoints as well as CLI applications using a bunch of simulated users which will bombard the endpoint using queries.
-Queries can be anything. SPARQL, SQL, Text and anything else you can fit in one line.
-
-## What can be benchmarked
-
-Iguana is capable of benchmarking and stresstesting the following applications
-
-* HTTP GET and POST endpoint (e.g. Triple Stores, REST Services, Question Answering endpoints)
-* CLI Applications which either
- * exit after every query
- * or awaiting input after each query
-
-## What Benchmarks are possible
-
-Every simulated User (named Worker in the following) gets a set of queries.
-These queries have to be saved in one file, whereas each query is one line.
-Hence everything you can fit in one line (e.g a SPARQL query, a text question, an RDF document) can be used as a query and a set of these queries represent the benchmark.
-Iguana will then let every Worker execute these queries against the endpoint.
diff --git a/docs/architecture.md b/docs/architecture.md
deleted file mode 100644
index 01f87b401..000000000
--- a/docs/architecture.md
+++ /dev/null
@@ -1,71 +0,0 @@
-# Architecture
-
-Iguanas architecture is build as generic as possible to ensure that your benchmark can be executed while you only have
-to create a configuration file which fits your needs.
-So ideally you do not need to code anything and can use Iguana out of the box.
-
-Iguana will parse your Configuration (YAML or JSON format) and will read which Endpoints/Applications you want to benchmark.
-What datasets if you have any and what your benchmark should accomplish.
-Do you just want to check how good your database/triple store performs against the state of the art?
-Does your new version out performs the old version?
-Do you want to check read and write performance?
-...
-
-Whatever you want to do you just need to provide Iguana your tested applications, what to benchmark and which queries to use.
-
-Iguana relys mainly on HTTP libraries, the JENA framework and java 11.
-
-
-## Overview
-
-
-Iguana will read the configuration, parse it and executes for each specified datasets, each specified connection with the benchmark tasks you specified.
-After the executions the results will be written as RDF. Either to a NTriple file or directly to a triple store.
-The results can be queried itself using SPARQL.
-
-Iguana currently consists of on implemented Task, the Stresstest.
-However, this task is very configurable and most definetly will met your needs if you want performance measurement.
-It starts a user defined amount of Workers, which will try to simulate real users/applications querying your Endpoint/Application.
-
-
-## Components
-
-Iguana consists of two components, the core controller and the result processor.
-
-### **core controller**
-
-The core which implements the Tasks and Workers to use. How HTTP responses should be handled.
-How to analyze the benchmark queries to give a little bit more extra information in the results.
-
-
-### **result processor**
-
-The result processor consist of the metrics to apply to the query execution results and how to save the results.
-Most of the SOtA metrics are implemented in Iguana. If one's missing it is pretty easy to add a metric though.
-
-By default it stores its result in a ntriple file. But you may configure it, to write the results directly to a Triple Store.
-On the processing side, it calculates various metrics.
-
-Per run metrics:
-* Query Mixes Per Hour (QMPH)
-* Number of Queries Per Hour (NoQPH)
-* Number of Queries (NoQ)
-* Average Queries Per Second (AvgQPS)
-
-Per query metrics:
-* Queries Per Second (QPS)
- * Number of successful and failed queries
- * result size
- * queries per second
- * sum of execution times
-
-You can change these in the Iguana Benchmark suite config.
-
-If you use the [basic configuration](https://github.com/dice-group/IGUANA/blob/master/example-suite.yml), it will save all mentioned metrics to a file called `results_{DD}-{MM}-{YYYY}_{HH}-{mm}.nt`
-
-## More Information
-
-* [SPARQL](https://www.w3.org/TR/sparql11-query/)
-* [RDF](https://www.w3.org/RDF/)
-* [Iguana @ Github](https://github.com/dice-group/Iguana)
-* [Our Paper from 2017](https://svn.aksw.org/papers/2017/ISWC_Iguana/public.pdf) (outdated)
diff --git a/docs/configuration/ahead-of-time-compilation.md b/docs/configuration/ahead-of-time-compilation.md
new file mode 100644
index 000000000..3f54387c5
--- /dev/null
+++ b/docs/configuration/ahead-of-time-compilation.md
@@ -0,0 +1,37 @@
+# Ahead of Time Compilation
+
+Because IGUANA is written in Java, the benchmark results might become inaccurate due to the architecture of the JVM.
+The benchmark results might appear to be slower at the beginning of the execution and faster at the end, even though the
+benchmarked system's performance remains constant.
+
+To minimize this effect, IGUANA uses GraalVM's ahead-of-time compilation feature.
+This feature compiles the Java code to a native executable, which can be run without the need for a JVM.
+
+This section explains how to compile IGUANA with GraalVM and how to use the compiled binary.
+
+## Prerequisites
+
+To compile IGUANA with GraalVM, you need to have [GraalVM](https://www.graalvm.org/) installed on your system.
+The `native-image` tool also requires some additional libraries to be installed on your system.
+The further prerequisites can be found [here](https://www.graalvm.org/latest/reference-manual/native-image/#prerequisites).
+
+The default target architecture for the native binary is `x86-64-v3` (Intel Haswell and AMD Excavator or newer).
+This and other settings can be adjusted in the `pom.xml` file.
+
+## Compilation
+
+To compile IGUANA with GraalVM, execute the following command:
+
+```bash
+mvn -Pnative -Dagent=true package
+```
+
+This command creates a native binary named `iguana` in the `target/` directory.
+
+## Usage
+
+The compiled executable can be run like any other executable and behaves the same as the Java version.
+
+```bash
+./iguana
+```
diff --git a/docs/configuration/language_processor.md b/docs/configuration/language_processor.md
new file mode 100644
index 000000000..f3fae6302
--- /dev/null
+++ b/docs/configuration/language_processor.md
@@ -0,0 +1,15 @@
+# Language Processor
+
+Language processors are used to process the response bodies of the HTTP requests that are executed by the workers.
+The processing is done to extract relevant information from the responses and store them in the results.
+
+Language processors are defined by the content type of the response body they process.
+They cannot be configured directly in the configuration file, but are used by the response body processors.
+
+Currently only the `SaxSparqlJsonResultCountingParser` language processor is supported for the `application/sparql-results+json` content type.
+
+## SaxSparqlJsonResultCountingParser
+
+The `SaxSparqlJsonResultCountingParser` is a language processor used to extract simple information from the responses of SPARQL endpoints that are in the `application/sparql-results+json` format.
+It counts the number of results, the number of variables,
+and the number of bindings from the response of a `SELECT` or `ASK` query.
diff --git a/docs/configuration/metrics.md b/docs/configuration/metrics.md
new file mode 100644
index 000000000..5e29522c4
--- /dev/null
+++ b/docs/configuration/metrics.md
@@ -0,0 +1,84 @@
+# Metrics
+
+Metrics are used to measure and compare the performance of the system during the stresstest.
+They are divided into task metrics, worker metrics, and query metrics.
+
+Task metrics are calculated for every query execution across the whole task.
+Worker metrics are calculated for every query execution of one worker.
+Query metrics are calculated for every execution of one query across one worker and across every worker.
+
+For a detailed description of how results for tasks, workers and queries are reported in the RDF result file, please refer to the section [RDF results](rdf_results.md).
+
+## Configuration
+
+The metrics are configured in the `metrics` section of the configuration file.
+To enable a metric, add an entry to the `metrics` list with the `type` of the metric.
+Some metrics (`PQPS`, `PAvgQPS`) require the configuration of a `penalty` value,
+which is the time in milliseconds that a failed query will be penalized with.
+
+```yaml
+metrics:
+ - type: "QPS"
+ - type: "AvgQPS"
+ - type: "PQPS"
+ penalty: 180000 # in milliseconds
+```
+
+If the `metrics` section is not present in the configuration file, the following **default** configuration is used:
+```yaml
+metrics:
+ - type: "AES"
+ - type: "EachQuery"
+ - type: "QPS"
+ - type: "AvgQPS"
+ - type: "NoQ"
+ - type: "NoQPH"
+ - type: "QMPH"
+```
+
+## Available metrics
+
+| Name | Configuration type | Additional parameters | Scope | Description |
+|--------------------------------------|--------------------|-----------------------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Queries per second | `QPS` | | query | The number of successfully executed queries per second. It is calculated by dividing the number of successfully executed queries |
+| Average queries per second | `AvgQPS` | | task, worker | The average number of queries successfully executed per second. It is calculated by dividing the sum of the QPS values of every query the task or worker has by the number of queries. |
+| Number of queries | `NoQ` | | task, worker | The number of successfully executed queries. This metric is calculated for each worker and for the whole task. |
+| Number of queries per hour | `NoQPH` | | task, worker | The number of successfully executed queries per hour. It is calculated by dividing the number of successfully executed queries by their sum of time (in hours) it took to execute them. The metric value for the task is the sum of the metric for each worker. |
+| Query mixes per hour | `QMPH` | | task, worker | The number of query mixes executed per hour. A query mix is the set of queries executed by a worker, or the whole task. This metric is calculated for each worker and for the whole task. It is calculated by dividing the number of successfully executed queries by the number of queries inside the query mix and by their sum of time (in hours) it took to execute them. |
+| Penalized queries per second | `PQPS` | `penalty` (in milliseconds) | query | The number of queries executed per second, penalized by the number of failed queries. It is calculated by dividing the number of successful and failed query executions by their sum of time (in seconds) it took to execute them. If a query fails, the time it took to execute it is set to the given `penalty` value. |
+| Penalized average queries per second | `PAvgQPS` | `penalty` (in milliseconds) | task, worker | The average number of queries executed per second, penalized by the number of failed queries. It is calculated by dividing the sum of the PQPS of each query the task or worker has executed by the number of queries. |
+| Aggregated execution statistics | `AES` | | task, worker | _see below_ |
+| Each execution statistic | `EachQuery` | | query | _see below_ |
+
+## Other metrics
+
+### Aggregated Execution Statistics (AES)
+This metric collects for each query that belongs to a worker or a task a number of statistics
+that are aggregated for each execution.
+
+| Name | Description |
+|---------------------|--------------------------------------------------------------|
+| `succeeded` | The number of successful executions. |
+| `failed` | The number of failed executions. |
+| `resultSize` | The size of the HTTP response. (only stores the last result) |
+| `timeOuts` | The number of executions that resulted with a timeout. |
+| `wrongCodes` | The number of HTTP status codes received that were not 200. |
+| `unknownExceptions` | The number of unknown exceptions during execution. |
+| `totalTime` | The total time it took to execute the queries. |
+
+The `resultSize` is the size of the HTTP response in bytes and is an exception to the aggregation.
+
+### Each Execution Statistic (EachQuery)
+This metric collects statistics for each execution of a query.
+
+| Name | Description |
+|----------------|-----------------------------------------------------------------------------------------------------------|
+| `run` | The number of the execution. |
+| `startTime` | The time stamp where the execution started. |
+| `time` | The time it took to execute the query. |
+| `success` | If the execution was successful. |
+| `code` | Numerical value of the end state of the execution. (success=0, timeout=110, http_error=111, exception=1) |
+| `resultSize` | The size of the HTTP response. |
+| `exception` | The exception that occurred during execution. (if any occurred) |
+| `httpCode` | The HTTP status code received. (if any was received) |
+| `responseBody` | The hash of the HTTP response body. (only if `parseResults` inside the stresstest has been set to `true`) |
diff --git a/docs/configuration/overview.md b/docs/configuration/overview.md
new file mode 100644
index 000000000..76b715332
--- /dev/null
+++ b/docs/configuration/overview.md
@@ -0,0 +1,298 @@
+# Configuration
+
+The configuration file for a benchmark suite can either be `.yaml`-file or a `.json`-file.
+YAML is recommended and all examples will be presented as YAML.
+
+## Example
+The following example shows a basic configuration for a benchmark suite as an introduction.
+
+```yaml
+dataset:
+ - name: "sp2b" # for documentation purposes
+
+connections:
+ - name: "fuseki"
+ endpoint: "http://localhost:3030/sparql"
+ dataset: "sp2b"
+
+tasks:
+ - type: "stresstest" # stresstest the endpoint
+ workers:
+ - type: "SPARQLProtocolWorker" # this worker type sends SPARQL queries over HTTP with the SPARQL protocol
+ number: 2 # generate 2 workers with the same configuration
+ connection: "fuseki" # the endpoint to which the workers are sending the queries to
+ queries:
+ path: "./example/suite/queries.txt" # the file with the queries
+ format: "one-per-line" # the format of the queries
+ completionTarget:
+ number: 1 # each worker stops after executing all queries once
+ timeout: "3 min" # a query will time out after 3 minutes
+ acceptHeader: "application/sparql-results+json" # the expected content type of the HTTP response (HTTP Accept header)
+ parseResults: false
+
+# calculate queries per second only for successful queries and the queries per second with a penalty for failed queries
+metrics:
+ - type: "PQPS"
+ penalty: 180000 # in milliseconds (3 minutes)
+ - type: "QPS"
+
+# store the results in an n-triples file and in CSV files
+storages:
+ - type: "rdf file"
+ path: "./results/result.nt"
+ - type: "csv file"
+ directory: "./results/"
+```
+
+This configuration defines a benchmark suite that stresstests a triplestore with two workers.
+
+The triplestore is named `fuseki` and is located at `http://localhost:3030/sparql`.
+The dataset, that is used for the benchmark, is named `sp2b`.
+During the stresstest the workers will send SPARQL queries
+that are located in the file `./example/suite/queries.txt` to the triplestore.
+They will stop after they have executed all queries once, which is defined by the `completionTarget`-property.
+
+After the queries have been executed, two metrics are calculated based on the results.
+The first metric is the `PQPS`-metric, which calculates the queries per second with a penalty for failed queries.
+The second metric is the `QPS`-metric, which calculates the queries per second only for successful queries.
+
+The results are stored in an RDF file at `./results/result.nt` and in CSV files in the directory `./results/`.
+
+## Structure
+
+The configuration file consists of the following six sections:
+- [Datasets](#Datasets)
+- [Connections](#Connections)
+- [Tasks](tasks.md)
+- [Response-Body-Processors](#Response-Body-Processor)
+- [Metrics](metrics.md)
+- [Storages](storages.md)
+
+Each section holds an array of their respective items.
+Each item type will be defined further in this documentation.
+The order of the sections is not important.
+The general structure of a suite configuration may look like this:
+
+```yaml
+tasks:
+ - # item 1
+ - # item 2
+ - # ...
+
+storages:
+ - # item 1
+ - # item 2
+ - # ...
+
+datasets:
+ - # item 1
+ - # item 2
+ - # ...
+
+connections:
+ - # item 1
+ - # item 2
+ - # ...
+
+
+responseBodyProcessors:
+ - # item 1
+ - # item 2
+ - # ...
+
+metrics:
+ - # item 1
+ - # item 2
+ - # ...
+```
+
+## Durations
+
+Durations are used to define time spans in the configuration.
+They can be used for the `timeout`-property of the workers or the response body processors or for the `completionTarget`-property of the tasks.
+Duration values can be defined as a XSD duration string or as a string with a number and a unit.
+The following units are supported:
+- `s` or `sec`or `secs` for seconds
+- `m` or `min` or `mins` for minutes
+- `h` or `hr` or `hrs` for hours
+- `d` or `day` or `days` for days
+
+Some examples for duration values:
+```yaml
+timeout: "2S" # 2 seconds
+timeout: "10s" # 10 seconds
+timeout: "PT10S" # 10 seconds
+```
+
+## Tasks
+The tasks are the core of the benchmark suite.
+They define the actual process of the benchmarking suite
+and are executed from top to bottom in the order they are defined in the configuration.
+At the moment, the `stresstest` is the only implemented task.
+The `stresstest`-task queries specified endpoints with the given queries and evaluates the performance of the endpoint
+by measuring the time each query execution took.
+After the execution of the queries, the task calculates the required metrics based on the measurements.
+
+The tasks are explained in more detail in the [Tasks](tasks.md) documentation.
+
+## Storages
+The storages define where and how the results of the benchmarking suite are stored.
+There are three types of storages that are supported at the moment:
+- `rdf file`
+- `csv file`
+- `triplestore`
+
+Each storage type will be explained in more detail in the [Storages](storages.md) documentation.
+
+## Datasets
+The datasets that have been used for the benchmark can be defined here.
+Right now, this is only used for documentation purposes.
+For example, you might want to know which dataset was loaded into a triplestore at the time a stresstest
+was executed.
+
+The datasets are therefore later on referenced in the `connections`-property
+to document which dataset has been loaded into which endpoint.
+
+### Properties
+Each dataset entry has the following properties:
+
+| property | required | description | example |
+|----------|----------|-----------------------------------------------------------------|------------------------|
+| name | yes | This is a descriptive name for the dataset. | `"sp2b"` |
+| file | no | File path of the dataset. (not used for anything at the moment) | `"./datasets/sp2b.nt"` |
+
+### Example
+```yaml
+datasets:
+ - name: "sp2b"
+ file: "./datasets/sp2b.nt"
+
+connections:
+ - name: "fuseki"
+ endpoint: "https://localhost:3030/query"
+ dataset: "sp2b"
+```
+
+As already mentioned, the `datasets`-property is only used for documentation.
+The information about the datasets will be stored in the results.
+For the csv storage, the above configuration might result with the following `task-configuration.csv`-file:
+
+| taskID | connection | version | dataset |
+|-------------------------------------------------------------|------------|---------|---------|
+| http://iguana-benchmark.eu/resource/1699354119-3273189568/0 | fuseki | v2 | sp2b |
+
+The resulting triples for the rdf file storage might look like this:
+
+```turtle
+ires:fuseki a iont:Connection ;
+ rdfs:label "fuseki" ;
+ iprop:dataset ires:sp2b .
+
+ires:sp2b a iont:Dataset ;
+ rdfs:label "sp2b" .
+```
+
+## Connections
+The connections are used to define the endpoints for the triplestores.
+The defined connections can later be used in the `tasks`-configuration
+to specify the endpoints for the benchmarking process.
+
+### Properties
+| property | required | description | example |
+|----------------------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------|
+| name | yes | This is a descriptive name for the connection. **(needs to be unique)** | `"fuseki"` |
+| version | no | This serves to document the version of the connection. It has no functional property. | `"v1.0.1"` |
+| dataset | no | This serves to document the dataset, that has been loaded into the specified connection. It has no functional property. **(needs to reference an already defined dataset in `datasets`)** | `"sp2b"` |
+| endpoint | yes | An URI at which the endpoint is located. | `"http://localhost:3030/query"` |
+| authentication | no | Basic authentication data for the connection. | _see below_ |
+| updateEndpoint | no | An URI at which an additional update-endpoint might be located. This is useful for triplestores that have separate endpoints for update queries. | `"http://localhost:3030/update"` |
+| updateAuthentication | no | Basic Authentication data for the updateEndpoint. | _see below_ |
+
+Iguana only supports the HTTP basic authentication for now.
+The authentication properties are objects that are defined as follows:
+
+| property | required | description | example |
+|----------|----------|---------------------------|--------------|
+| user | yes | The user name. | `"admin"` |
+| password | yes | The password of the user. | `"password"` |
+
+### Example
+
+```yaml
+datasets:
+ - name: "wikidata"
+
+connections:
+ - name: "fuseki"
+ endpoint: "https://localhost:3030/query"
+ - name: "tentris"
+ version: "v0.4.0"
+ dataset: "wikidata" # needs to reference an existing definition in datasets
+ endpoint: "https://localhost:9080/query"
+ authentication:
+ user: "admin"
+ password: "password"
+ updateEndpoint: "https://localhost:8080/update"
+ updateAuthentication:
+ user: "updateUser"
+ password: "123"
+```
+
+
+## Response-Body-Processor
+The response body processors are used
+to process the response bodies that are received for each query from the benchmarked endpoints.
+The processors extract relevant information from the response bodies and store them in the results.
+Processors are defined by the content type of the response body they process.
+At the moment, only the `application/sparql-results+json` content type is supported.
+
+The response body processors are explained in more detail in the [Response-Body-Processor](response_body_processor) documentation.
+
+## Metrics
+Metrics are used to compare the performance of the benchmarked endpoints.
+The metrics are calculated from the results of the benchmarking tasks.
+Depending on the type of the metric, they are calculated for each query, for each worker, or for the whole task.
+
+Each metric will be explained in more detail in the [Metrics](metrics.md) documentation.
+
+## Basic Example
+
+```yaml
+datasets:
+ - name: "sp2b"
+
+connections:
+ - name: "fuseki"
+ dataset: "sp2b"
+ endpoint: "http://localhost:3030/sp2b"
+
+tasks:
+ - type: "stresstest"
+ workers:
+ - number: 2
+ type: "SPARQLProtocolWorker"
+ parseResults: true
+ acceptHeader: "application/sparql-results+json"
+ queries:
+ path: "./example/suite/queries/"
+ format: "folder"
+ completionTarget:
+ number: 1
+ connection: "fuseki"
+ timeout: "2S"
+
+responseBodyProcessors:
+ - contentType: "application/sparql-results+json"
+ threads: 1
+
+metrics:
+ - type: "PQPS"
+ penalty: 100
+ - type: "QPS"
+
+storages:
+ - type: "rdf file"
+ path: "./results/result.nt"
+ - type: "csv file"
+ directory: "./results/"
+```
diff --git a/docs/configuration/queries.md b/docs/configuration/queries.md
new file mode 100644
index 000000000..262f1b98c
--- /dev/null
+++ b/docs/configuration/queries.md
@@ -0,0 +1,95 @@
+# Queries
+
+Benchmarks often involve running a series of queries against a database and measuring their performances.
+The query handler in Iguana is responsible for loading and selecting queries for the benchmarking process.
+
+Inside the stresstest task, the query handler is configured with the `queries` property.
+Every worker instance of the same worker configuration will use the same query handler.
+The `queries` property is an object that contains the following properties:
+
+| property | required | default | description | example |
+|-----------|----------|----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------|
+| path | yes | | The path to the queries. It can be a file or a folder. | `./example/suite/queries/` |
+| format | no | `one-per-line` | The format of the queries. | `folder` or `separator` or `one-per-line` |
+| separator | no | `""` | The separator that should be used if the format is set to `separator`. | `\n###\n` |
+| caching | no | `true` | If set to `true`, the queries will be cached into memory. If set to `false`, the queries will be read from the file system every time they are needed. | `false` |
+| order | no | `linear` | The order in which the queries are executed. If set to `linear` the queries will be executed in their order inside the file. If `format` is set to `folder`, queries will be sorted by their file name first. | `random` or `linear` |
+| seed | no | `0` | The seed for the random number generator that selects the queries. If multiple workers use the same query handler, their seed will be the sum of the given seed and their worker id. | `12345` |
+| lang | no | `SPARQL` | Not used for anything at the moment. | |
+
+## Format
+
+### One-per-line
+The `one-per-line` format is the default format.
+In this format, every query is written in a single line inside one file.
+
+In this example, the queries are written in a single file, each query in a single line:
+```
+SELECT DISTINCT * WHERE { ?s ?p ?o }
+SELECT DISTINCT ?s ?p ?o WHERE { ?s ?p ?o }
+```
+
+### Folder
+It is possible to write every query in a separate file and put them all in a folder.
+Queries will be sorted by their file name before they are read.
+
+In this example, the queries are written in separate files inside the folder `./example/suite/queries/`:
+```
+./example/suite/queries/
+├── query1.txt
+└── query2.txt
+```
+
+The file `query1.txt` contains the following query:
+```
+SELECT DISTINCT *
+WHERE {
+ ?s ?p ?o
+}
+```
+
+The file `query2.txt` contains the following query:
+```
+SELECT DISTINCT ?s ?p ?o
+WHERE {
+ ?s ?p ?o
+}
+```
+
+### Separator
+It is possible to write every query in a single file and separate them with a separator.
+The separator can be set with the `separator` property.
+Iguana will then split the file into queries based on the separator.
+If the `separator` property is set to an empty string `""` (default) the queries will be separated by an empty line.
+The separator string can also contain escape sequences like `\n` or `\t`.
+
+In this example, the queries inside this file are separated by a line consisting of the string `###`:
+```
+SELECT DISTINCT *
+WHERE {
+ ?s ?p ?o
+}
+###
+SELECT DISTINCT ?s ?p ?o
+WHERE {
+ ?s ?p ?o
+}
+```
+The `separator` property should be set to `"\n###\n"`. (be aware of different line endings on different operating systems)
+
+## Example
+```yaml
+tasks:
+ - type: "stresstest"
+ workers:
+ - type: "SPARQLProtocolWorker"
+ queries:
+ path: "./example/suite/queries.txt"
+ format: "separator"
+ separator: "\n###\n"
+ caching: false
+ order: "random"
+ seed: 12345
+ lang: "SPARQL"
+ # ... additional worker properties
+```
diff --git a/docs/configuration/rdf_results.md b/docs/configuration/rdf_results.md
new file mode 100644
index 000000000..db74c7687
--- /dev/null
+++ b/docs/configuration/rdf_results.md
@@ -0,0 +1,146 @@
+# RDF Results
+The differences between task, worker, and query metrics will be explained in more detail with the following examples.
+The results shown have been generated with the `rdf file` storage type.
+
+## Task and Worker Metrics
+The first excerpt shows the results for the task `ires:1710247002-3043500295/0` and its worker
+`ires:1710247002-3043500295/0/0`:
+
+```turtle
+
+ a iont:Stresstest , iont:Task ;
+ iprop:AvgQPS 84.121083502 ;
+ iprop:NoQ 16 ;
+ iprop:NoQPH 21894.0313677612 ;
+ iprop:QMPH 1287.8841981036 ;
+ iprop:endDate "2024-03-12T12:36:48.323Z"^^ ;
+ iprop:metric ires:QMPH , ires:NoQPH , ires:AvgQPS , ires:NoQ ;
+ iprop:noOfWorkers "1"^^ ;
+ iprop:query (iri of every query that has been executed inside the task) ;
+ iprop:startDate "2024-03-12T12:36:42.636Z"^^ ;
+ iprop:workerResult .
+
+
+ a iont:Worker ;
+ iprop:AvgQPS 84.121083502 ;
+ iprop:NoQ 16 ;
+ iprop:NoQPH 21894.0313677612 ;
+ iprop:QMPH 1287.8841981036 ;
+ iprop:connection ires:fuseki ;
+ iprop:endDate "2024-03-12T12:36:48.322204Z"^^ ;
+ iprop:metric ires:NoQ , ires:NoQPH , ires:QMPH , ires:AvgQPS ;
+ iprop:noOfQueries "17"^^ ;
+ iprop:noOfQueryMixes "1"^^ ;
+ iprop:query (iri of every query the worker has executed) ;
+ iprop:startDate "2024-03-12T12:36:42.6457629Z"^^ ;
+ iprop:timeOut "PT10S"^^ ;
+ iprop:workerID "0"^^ ;
+ iprop:workerType "SPARQLProtocolWorker" .
+```
+
+- The IRI `ires:1710247002-3043500295/0` represents the task `0` of the benchmark suite `1710247002-3043500295`.
+- The IRI `ires:1710247002-3043500295/0/0` represents the worker `0` of the task described above.
+
+Both task and worker contain results of the `AvgQPS`, `NoQ`, `NoQPH`, and `QMPH` metrics.
+These metrics are calculated for the whole task and for each worker, which can be seen in the example.
+Because the task of this example only had one worker, the results are the same.
+
+Additional information about the task and worker, besides the metric results, are stored as well.
+The following properties are stored for the task:
+- `noOfWorkers`: The number of workers that executed the task.
+- `query`: The IRI of every query that was executed by the task.
+- `startDate`: The time when the task started.
+- `endDate`: The time when the task ended.
+- `workerResult`: The IRIs of the workers that executed the task.
+- `metric`: The IRIs of the metrics that were calculated for the task.
+
+The following properties are stored for the worker:
+- `connection`: The IRI of the connection that the worker used.
+- `noOfQueries`: The number of queries.
+- `noOfQueryMixes`: The number of queries mixes that the worker executed (mutually exclusive to `timeLimit`).
+- `timeLimit`: The time duration for which the worker has executed queries (mutually exclusive to `noOfQueryMixes`).
+- `query`: The IRI of every query that the worker executed.
+- `startDate`: The time when the worker started.
+- `endDate`: The time when the worker ended.
+- `timeOut`: The maximum time a query execution should take.
+- `workerID`: The id of the worker.
+- `workerType`: The type of the worker.
+
+## Query Metrics
+Every query of each query handler has its own id.
+It consists of a hash value of the query handler and the query id in this format:
+`ires::`.
+In this example, results for the query `ires:1181728761:0` are shown:
+
+```turtle
+
+ a iont:ExecutedQuery ;
+ iprop:QPS 18.975908187 ;
+ iprop:failed 0 ;
+ iprop:queryID ires:1181728761:0 ;
+ iprop:resultSize 212 ;
+ iprop:succeeded 1 ;
+ iprop:timeOuts 0 ;
+ iprop:totalTime "PT0.0526984S"^^ ;
+ iprop:unknownException 0 ;
+ iprop:wrongCodes 0 .
+
+
+ a iont:ExecutedQuery ;
+ iprop:QPS 18.975908187 ;
+ iprop:failed 0 ;
+ iprop:queryExecution ;
+ iprop:queryID ires:1181728761:0 ;
+ iprop:resultSize 212 ;
+ iprop:succeeded 1 ;
+ iprop:timeOuts 0 ;
+ iprop:totalTime "PT0.0526984S"^^ ;
+ iprop:unknownException 0 ;
+ iprop:wrongCodes 0 .
+```
+
+The IRI `` consists of the following
+segments:
+- `ires:1710247002-3043500295` is the IRI of the benchmark suite.
+- `ires:1710247002-3043500295/0` is the IRI of the first task.
+- `ires:1710247002-3043500295/0/0` is the IRI of the first task's worker.
+- `1181728761:0` is the query id.
+
+The suite id is made up of the timestamp and the hash value of the suite configuration in this pattern:
+`ires:-`.
+
+The subject `` represents the results of the query
+`ires:1181728761:0` from first worker of the task `1710247002-3043500295/0`.
+
+The subject `` represents the results of the query
+`ires:1181728761:0` from every worker across the whole task `1710247002-3043500295/0`.
+
+Results of query metrics, like the `QPS` metric (also the `AES` metric),
+are therefore calculated for each query of each worker and for each query of the whole task.
+
+The `iprop:queryExecution` property of ``
+contains the IRIs of the executions of that query from that worker.
+These will be explained in the next section.
+
+## Each Execution Statistic
+
+With the `EachQuery` metric Iguana stores the statistics of each execution of a query.
+The following excerpt shows the execution statistics of the query `ires:1181728761:0`:
+
+```turtle
+
+ iprop:code "0"^^ ;
+ iprop:httpCode "200" ;
+ iprop:queryID ires:1181728761:0 ;
+ iprop:responseBody ;
+ iprop:resultSize "212"^^ ;
+ iprop:run 1 ;
+ iprop:startTime "2024-03-12T12:36:42.647764Z"^^ ;
+ iprop:success true ;
+ iprop:time "PT0.0526984S"^^ .
+```
+
+The IRI `` consists of the worker
+query IRI as described above and the run number of the query execution.
+
+The properties of the `EachQuery` metric are described in the [metrics](./metrics.md) section.
diff --git a/docs/configuration/response_body_processor.md b/docs/configuration/response_body_processor.md
new file mode 100644
index 000000000..5b4cc7259
--- /dev/null
+++ b/docs/configuration/response_body_processor.md
@@ -0,0 +1,25 @@
+# Response-Body-Processor
+
+The response body processor is used
+to process the response bodies of the HTTP requests that are executed by the workers.
+The processing is done to extract relevant information from the responses and store them in the results.
+
+Iguana supports multiple response body processors that are defined by the content type of the response body they process.
+
+Currently only the `application/sparql-results+json` content type is supported,
+and it only uses the `SaxSparqlJsonResultCountingParser` language processor
+to extract simple information from the responses.
+
+Workers send the response bodies to the response body processors,
+after receiving the full response bodies from the HTTP requests.
+Response bodies are processed in parallel by the number of threads that are defined in the configuration.
+
+To use a response body processor, it needs to be defined in the configuration file with the `contentType` property
+in the `responseBodyProcessors` list.
+
+## Properties
+| property | required | description | example |
+|-------------|----------|--------------------------------------------------------------------------------------------------------------------|-------------------------------------|
+| contentType | yes | The content type of the response body. | `"application/sparql-results+json"` |
+| threads | no | The number of threads that are used to process the response bodies. (default is 1) | `2` |
+| timeout | no | The maximum duration that the response body processor can take to process a response body. (default is 10 minutes) | `10m` |
\ No newline at end of file
diff --git a/docs/configuration/storages.md b/docs/configuration/storages.md
new file mode 100644
index 000000000..775ccdac1
--- /dev/null
+++ b/docs/configuration/storages.md
@@ -0,0 +1,89 @@
+# Storages
+
+Storages are used to store the results of the benchmark suite.
+It is possible to use multiple storages at the same time.
+They can be configured with the `storages` property in the configuration file
+by providing a list of storage configurations.
+
+## Example
+
+```yaml
+storages:
+ - type: "csv file"
+ directory: "./results"
+ - type: "rdf file"
+ path: "./results"
+ - type: "triplestore"
+ endpoint: "http://localhost:3030/ds"
+ username: "admin"
+ password: "password"
+```
+
+The following values for the `type` property are supported:
+
+- [csv file](#csv-file-storage)
+- [rdf file](#rdf-file-storage)
+- [triplestore](#triplestore-storage)
+
+## CSV File Storage
+
+The csv file storage writes the results of the benchmark suite to multiple csv files.
+It only has a single property, `directory`,
+which defines the path to the directory where the csv files should be written to.
+
+Inside the directory, a new directory for the execution of the benchmark suite will be created.
+The name of the directory is `suite--` where
+the `timestamp` is the benchmark's time of execution and `config-hash` the hash value of the benchmark configuration.
+
+The following shows an example of the directory structure and created files of the csv storage:
+
+```text
+suite-1710241608-1701417056/
+├── suite-summary.csv
+├── task-0
+│ ├── application-sparql+json
+│ │ └── sax-sparql-result-data.csv
+│ ├── each-execution-worker-0.csv
+│ ├── query-summary-task.csv
+│ ├── query-summary-worker-0.csv
+│ └── worker-summary.csv
+└── task-configuration.csv
+```
+
+- The `suite-summary.csv` file contains the summary of each task.
+- The `task-configuration.csv` file contains information about the configuration of each task.
+- Inside the `task-0` directory, the results of the task with the id `0` are stored.
+ - The `each-execution-worker-0.csv` file contains the metric results of each query execution for `worker 0`.
+ - The `query-summary-task.csv` file contains the summary of the metric results for every query inside the task.
+ - The `query-summary-worker-0.csv` file contains the summary of the metric results for every query of `worker 0`.
+ - The `worker-summary.csv` file contains the summary of metrics for each worker of the task.
+
+The `application-sparql+json` directory contains results from Language Processors
+that process results with the `application/sparql+json` content type.
+Each Language Processor creates their own files in their respective directory.
+
+## RDF File Storage
+
+The rdf file storage writes the results of the benchmark suite to a single rdf file.
+
+It only has a single property, `path`,
+which defines the path to the rdf file where the results should be written to.
+The path can be either a file or a directory.
+The file extension of the file determines in which format the rdf data is stored
+(e.g., `.nt` for n-triples, `.ttl` for turtle).
+
+If the path is a directory or a file that already exists,
+the file will be a turtle file with a timestamp as its name.
+
+## Triplestore Storage
+
+The triplestore storage writes the results of the benchmark suite directly to a triplestore as triples,
+similar to the rdf file storage.
+
+It has the following properties:
+
+- `endpoint`: The update endpoint of the triplestore.
+- `username`: The username for the authentication of the triplestore.
+- `password`: The password for the authentication of the triplestore.
+
+The `username` and `password` properties are optional.
diff --git a/docs/configuration/tasks.md b/docs/configuration/tasks.md
new file mode 100644
index 000000000..95162ed33
--- /dev/null
+++ b/docs/configuration/tasks.md
@@ -0,0 +1,50 @@
+# Tasks
+The tasks are the core of the benchmark suite.
+They define the actual process of the benchmarking suite
+and are executed from top to bottom in the order they are defined in the configuration.
+At the moment, the `stresstest` is the only implemented task.
+
+Tasks are defined in the `tasks` section of the configuration and are distinguished by the `type` property.
+
+## Example
+```yaml
+tasks:
+ - type: "stresstest"
+ # properties of the task
+ # ...
+```
+
+## Stresstest
+The `stresstest`-task queries the specified endpoints in rapid succession with the given queries.
+It measures the time it takes to execute each query and calculates the required metrics based
+on the measurements.
+The task is used to measure the performance of the endpoint for each query.
+The task is configured with the following properties:
+
+| property | required | description |
+|---------------|----------|--------------------------------------------------------------|
+| workers | yes | An array that contains worker configurations. |
+| warmupworkers | no | An array that contains worker configurations for the warmup. |
+
+The stresstest uses workers to execute the queries, which are supposed to simulate users.
+Each worker has its own set of queries and executes them parallel to the other workers.
+
+Warmup workers have the same functionality as normal workers,
+but their results won't be processed and stored.
+The stresstest runs the warmup workers before the actual workers.
+They're used to warm up the system before the actual benchmarking starts.
+
+For more information about the worker configuration, see [here](./workers.md).
+
+### Example
+```yaml
+tasks:
+ - type: "stresstest"
+ workers:
+ - type: "SPARQLProtocolWorker"
+ # ... worker properties
+ warmupworkers:
+ - type: "SPARQLProtocolWorker"
+ # ...
+```
+
diff --git a/docs/configuration/workers.md b/docs/configuration/workers.md
new file mode 100644
index 000000000..91ae5e852
--- /dev/null
+++ b/docs/configuration/workers.md
@@ -0,0 +1,137 @@
+# Workers
+The stresstest uses workers to execute the queries, which are supposed to simulate users.
+Each worker has its own set of queries and executes them parallel to the other workers.
+
+Iguana supports multiple worker types, but currently only the `SPARQLProtocolWorker` is implemented.
+Workers have the common `type` property which defines the type of the worker.
+
+```yaml
+tasks:
+ - type: "stresstest"
+ workers:
+ - type: "SPARQLProtocolWorker"
+ # properties of the worker
+ # ...
+ - type: "SPARQLProtocolWorker"
+ # properties of the worker
+ # ...
+```
+
+## SPARQLProtocolWorker
+
+The `SPARQLProtocolWorker` is a worker that sends SPARQL queries to an endpoint using the SPARQL protocol.
+The worker can be configured with the following properties:
+
+| property | required | default | description |
+|------------------|----------|-------------|-----------------------------------------------------------------------------------------------------------------|
+| number | no | `1` | The number of workers that should be initiated with that same configuration. |
+| queries | yes | | The configuration of the query handler these workers should use. (see [here](./queries.md)) |
+| completionTarget | yes | | Either defines how many queries the worker should send, or how long it should send them. |
+| connection | yes | | The name of the connection that the worker should use. (needs to reference an already defined connection) |
+| timeout | yes | | The duration for the query timeout. |
+| acceptHeader | no | | The accept header that the worker should use for the HTTP requests. |
+| requestType | no | `get query` | The request type that the worker should use. |
+| parseResults | no | `true` | Whether the worker should parse the results. |
+
+Each property is explained in more detail below.
+
+### Example
+```yaml
+connection:
+ - name: "fuseki"
+ dataset: "sp2b"
+ endpoint: "http://localhost:3030/sp2b"
+
+tasks:
+ - type: "stresstest"
+ workers:
+ - type: "SPARQLProtocolWorker"
+ number: 2 # two workers with the same configuration will be initiated
+ queries: # the query handler configuration, both workers will use the same query handler
+ path: "./example/suite/queries/"
+ format: "folder"
+ completionTarget:
+ number: 1 # each query will be executed once
+ connection: "fuseki" # the worker will use the connection with the name "fuseki", which is defined above
+ timeout: "2S"
+ acceptHeader: "application/sparql-results+json"
+ requestType: "get query"
+ parseResults: true
+```
+
+### Number
+
+The `number` property defines the number of workers that should be initiated with the same configuration.
+Workers with the same configuration will use the same query handler instance.
+
+### Queries
+
+The `queries` property is the configuration of the query handler that the worker should use.
+The query handler is responsible for loading and selecting the queries that the worker should execute.
+The query handler configuration is explained in more detail [here](./queries.md).
+
+### Completion Target
+The `completionTarget` property defines when the worker should stop executing queries.
+The property takes an object as its value that contains either one of the following properties:
+- `number`: The number of times the worker should execute each query.
+- `duration`: The duration during which the worker should iterate and execute every query.
+
+Example:
+```yaml
+tasks:
+ - type: "stresstest"
+ workers:
+ - type: "SPARQLProtocolWorker"
+ number: 1
+ completionTarget:
+ number: 100 # execute each query 100 times
+ # ...
+ - type: "SPARQLProtocolWorker"
+ number: 1
+ completionTarget:
+ duration: "10s" # execute queries for 10 seconds
+ # ...
+```
+
+### Timeout
+The `timeout` property defines the maximum time a query execution should take,
+this includes the time it takes to send the request and to receive the response.
+If the timeout is reached, the worker will mark it as failed,
+cancel the HTTP request and continue with the execution of the next query.
+
+The system that's being tested should make sure that it's able
+to abort the further execution of the query if the timeout has been reached
+(e.g., by using a timeout parameter for the system, if available).
+Otherwise, problems like high resource usage or other issues might occur.
+
+### Request Type
+The `requestType` property defines the type of the HTTP request that the worker should use.
+It consists of a string that can be one of the following values:
+
+| request type | HTTP method | Content-Type header value | description |
+|-------------------------|-------------|-------------------------------------|----------------------------------------------------------------------------------------------------------------|
+| `"get query"` | `GET` | | The worker will send a `GET` request with a `query` parameter that contains the query. |
+| `"post query"` | `POST` | `application/sparq-query` | The body will contain the query. |
+| `"post update"` | `POST` | `application/sparq-update` | The body will contain the update query. |
+| `"post url-enc query"` | `POST` | `application/x-www-form-urlencoded` | The body will contain the a url-encoded key-value pair with the key being `query` and the query as the value. |
+| `"post url-enc update"` | `POST` | `application/x-www-form-urlencoded` | The body will contain the a url-encoded key-value pair with the key being `update` and the query as the value. |
+
+### Accept Header
+
+The `acceptHeader` property defines the value for the `Accept` header of the HTTP requests that a worker sends to the defined endpoint.
+This property also affects the [Response-Body-Processors](./overview#Response-Body-Processor)
+that are used to process the response bodies.
+
+### Parse Results
+
+The `parseResults` property defines whether the worker should parse the results of the queries.
+If the property is set to `true`,
+the worker will send the response body to the [Response-Body-Processors](./overview#Response-Body-Processor) for processing
+and calculate hash values for the response bodies.
+If the property is set to `false`,
+the worker will not parse the response bodies and will not calculate hash values for the response bodies.
+
+Setting the property to `false` can improve the performance of the worker.
+This means that the worker is able to measure the performance more accurately.
+If the property is set to `true`, the worker will temporarily store the whole response bodies in memory for processing.
+If the property is set to `false`, the worker will discard any received bytes from the response.
diff --git a/docs/develop/architecture.md b/docs/develop/architecture.md
deleted file mode 100644
index b051238e4..000000000
--- a/docs/develop/architecture.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Test1
-
-## Test2
diff --git a/docs/develop/extend-lang.md b/docs/develop/extend-lang.md
deleted file mode 100644
index 4285fdd8a..000000000
--- a/docs/develop/extend-lang.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# Extend Languages
-
-If you want to add query specific statistics and/or using the correct result size for an HTTP Worker (Post or Get) you can do so.
-(This may be interesting if you're not using SPARQL)
-
-Let's start by implementing the `LanguageProcessor`
-
-```java
-@Shorthand("lang.MyLanguage")
-public class MyLanguageProcessor implements LanguageProcessor {
-
- @Override
- public String getQueryPrefix() {
- }
-
-
- @Override
- public Model generateTripleStats(List queries, String resourcePrefix, String taskID) {
- }
-
- @Override
- public Long getResultSize(CloseableHttpResponse response) throws ParserConfigurationException, SAXException, ParseException, IOException {
- }
-
- @Override
- Long getResultSize(Header contentTypeHeader, BigByteArrayOutputStream content) throws ParserConfigurationException, SAXException, ParseException, IOException{
- }
-
- @Override
- long readResponse(InputStream inputStream, BigByteArrayOutputStream responseBody) throws IOException{
- }
-
-
-}
-```
-
-## Query prefix
-
-Set a query prefix which will be used in the result set, f.e. "sql"
-
-```java
- @Override
- public String getQueryPrefix() {
- return "sql";
- }
-```
-
-## Generate Query Statistics
-
-Generating query specific statistics (which will be added in the result file)
-
-You will get the queries (containg of an ID and the query itself) a resourcePrefix you may use to create the URIs and the current taskID.
-
-A basic pretty standard exmaple is
-
-```java
- @Override
- public Model generateTripleStats(List queries, String resourcePrefix, String taskID) {
- Model model = ModelFactory.createDefaultModel();
- for(QueryWrapper wrappedQuery : queries) {
- Resource subject = ResourceFactory.createResource(COMMON.RES_BASE_URI + resourcePrefix + "/" + wrappedQuery.getId());
- model.add(subject, RDF.type, Vocab.queryClass);
- model.add(subject, Vocab.rdfsID, wrappedQuery.getId().replace(queryPrefix, "").replace("sql", ""));
- model.add(subject, RDFS.label, wrappedQuery.getQuery().toString());
-
- //ADD YOUR TRIPLES HERE which contains query specific statistics
- }
- return model;
-
- }
-```
-
-## Get the result size
-
-To generate the correct result size in the result file do the following
-
-```java
- @Override
- public Long getResultSize(CloseableHttpResponse response) throws ParserConfigurationException, SAXException, ParseException, IOException {
-
-
- InputStream inStream = response.getEntity().getContent();
- Long size = -1L;
- //READ INSTREAM ACCORDINGLY
-
-
- return size;
- }
-
-
- @Override
- public Long getResultSize(Header contentTypeHeader, BigByteArrayOutputStream content) throws ParserConfigurationException, SAXException, ParseException, IOException {
- //Read content from Byte Array instead of InputStream
- InputStream is = new BigByteArrayInputStream(content);
- Long size=-1L;
- ...
-
- return size;
- }
-
- @Override
- public long readResponse(InputStream inputStream, BigByteArrayOutputStream responseBody) throws IOException {
- //simply moves content from inputStream to the byte array responseBody and returns the size;
- //will be used for parsing the anwser in another thread.
- return Streams.inputStream2ByteArrayOutputStream(inputStream, responseBody);
- }
-
-
-```
-
diff --git a/docs/develop/extend-metrics.md b/docs/develop/extend-metrics.md
deleted file mode 100644
index cd5667d36..000000000
--- a/docs/develop/extend-metrics.md
+++ /dev/null
@@ -1,107 +0,0 @@
-# Extend Metrics
-
-Developed a new metric or simply want to use one that isn't implemented?
-
-Start by extending the `AbstractMetric`
-
-```java
-package org.benchmark.metric
-
-@Shorthand("MyMetric")
-public class MyMetric extends AbstractMetric{
-
- @Override
- public void receiveData(Properties p) {
- }
-
- @Override
- public void close() {
- callbackClose();
- super.close();
-
- }
-
- protected void callbackClose() {
- //ADD YOUR CLOSING HERE
- }
-}
-```
-
-## Receive Data
-
-This method will receive all the results during the benchmark.
-
-You'll receive a few values regarding that one query execution, the time it took, if it succeeded, if not if it was a timeout, a wrong HTTP Code or unkown.
-Further on the result size of the query.
-
-If your metric is a single value metric you can use the `processData` method, which will automatically add each value together.
-However if your metric is query specific you can use the `addDataToContainter` method. (Look at the [QPSMetric](https://github.com/dice-group/IGUANA/blob/master/iguana.resultprocessor/src/main/java/org/aksw/iguana/rp/metrics/impl/QPSMetric.java).
-
-Be aware that both mehtods will save the results for each worker used. This allows to calcualte the overall metric as well the metric for each worker itself.
-
-We will go with the single-value metric for now.
-
-
-An example on how to retrieve every possible value and saving the time and success.
-
-```java
- @Override
- public void receiveData(Properties p) {
-
- double time = Double.parseDouble(p.get(COMMON.RECEIVE_DATA_TIME).toString());
- long tmpSuccess = Long.parseLong(p.get(COMMON.RECEIVE_DATA_SUCCESS).toString());
- long success = tmpSuccess>0?1:0;
- long failure = success==1?0:1;
- long timeout = tmpSuccess==COMMON.QUERY_SOCKET_TIMEOUT?1:0;
- long unknown = tmpSuccess==COMMON.QUERY_UNKNOWN_EXCEPTION?1:0;
- long wrongCode = tmpSuccess==COMMON.QUERY_HTTP_FAILURE?1:0;
- if(p.containsKey(COMMON.RECEIVE_DATA_SIZE)) {
- size = Long.parseLong(p.get(COMMON.RECEIVE_DATA_SIZE).toString());
- }
-
- Properties results = new Properties();
- results.put(TOTAL_TIME, time);
- results.put(TOTAL_SUCCESS, success);
-
- Properties extra = getExtraMeta(p);
- processData(extra, results);
- }
-```
-
-
-## Close
-
-In this method you should finally calculate your metric and send the results.
-
-```java
- protected void callbackClose() {
- //create model to contain results
- Model m = ModelFactory.createDefaultModel();
-
- Property property = getMetricProperty();
- Double sum = 0.0;
-
- // Go over each worker and add metric results to model.
- for(Properties key : dataContainer.keySet()){
- Double totalTime = (Double) dataContainer.get(key).get(TOTAL_TIME);
- Integer success = (Integer) dataContainer.get(key).get(TOTAL_SUCCESS);
- Double noOfQueriesPerHour = hourInMS*success*1.0/totalTime;
- sum+=noOfQueriesPerHour;
- Resource subject = getSubject(key);
- m.add(getConnectingStatement(subject));
- m.add(subject, property, ResourceFactory.createTypedLiteral(noOfQueriesPerHour));
- }
-
- // Add overall metric to model
- m.add(getTaskResource(), property, ResourceFactory.createTypedLiteral(sum));
-
- //Send data to storage
- sendData(m);
- }
-
-
-```
-
-## Constructor
-
-The constructor parameters will be provided the same way the Task get's the parameters, thus simply look at [Extend Task](../extend-task).
diff --git a/docs/develop/extend-queryhandling.md b/docs/develop/extend-queryhandling.md
deleted file mode 100644
index 6b1702bc1..000000000
--- a/docs/develop/extend-queryhandling.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# Extend Query Handling
-
-If you want to use another query generating method as the implemented ones you can do so.
-
-Start by extend the `AbstractWorkerQueryHandler`. It will split up the generation for UPDATE queries and Request queries.
-
-```java
-package org.benchmark.query
-
-
-public class MyQueryHandler extends AbstractWorkerQueryHandler{
-
- protected abstract QuerySet[] generateQueries(String queryFileName) {
-
- }
-
- protected abstract QuerySet[] generateUPDATE(String updatePath) {
-
- }
-
-}
-
-```
-
-for simplicity we will only show the `generateQueries` as it is pretty much the same.
-However be aware that the `generateUPDATE` will use a directory or file instead of just a query file.
-
-## Generate Queries
-
-The class will get a query file containing all the queries.
-How you read them and what to do with them is up to you.
-You just need to return an array of `QuerySet`s
-
-A query set is simply a container which contains the name/id of the query as well as the query or several queries (f.e. if they are of the same structure but different values).
-For simplicity we assume that we deal with only one query per query set.
-
-Parse your file and for each query create a QuerySet
-
-
-```java
- protected QuerySet[] generateQueries(String queryFileName) {
- File queryFile = new File(queryFileName);
- List ret = new LinkedList();
-
- int id=0;
- //TODO parse your queries
- ...
-
- ret.add(new InMemQuerySet(idPrefix+id++, queryString));
- ...
-
-
- return ret.toArray(new QuerySet[]{});
- }
-```
-
-This function will parse your query accodringly and add an In Memory QuerySet (another option is a File Based Query Set, where each QuerySet will be stored in a file and IO happens during the benchmark itself.
diff --git a/docs/develop/extend-result-storages.md b/docs/develop/extend-result-storages.md
deleted file mode 100644
index 95ab89779..000000000
--- a/docs/develop/extend-result-storages.md
+++ /dev/null
@@ -1,51 +0,0 @@
-#Extend Result Storages
-
-If you want to use a different storage than RDF you can extend the storages
-
-However it is highly optimized for RDF so we suggest to work on top of the `TripleBasedStorage`
-
-```java
-package org.benchmark.storage
-
-@Shorthand("MyStorage")
-public class MyStorage extends TripleBasedStorage {
-
- @Override
- public void commit() {
-
- }
-
-
- @Override
- public String toString(){
- return this.getClass().getSimpleName();
- }
-
-}
-
-```
-
-## Commit
-
-This should take all the current results, store them and remove them from memory.
-
-You can access the results at the Jena Model `this.metricResults`.
-
-For example:
-
-```java
-
- @Override
- public void commit() {
- try (OutputStream os = new FileOutputStream(file.toString(), true)) {
- RDFDataMgr.write(os, metricResults, RDFFormat.NTRIPLES);
- metricResults.removeAll();
- } catch (IOException e) {
- LOGGER.error("Could not commit to NTFileStorage.", e);
- }
- }
-```
-
-## Constructor
-
-The constructor parameters will be provided the same way the Task get's the parameters, thus simply look at [Extend Task](../extend-task).
diff --git a/docs/develop/extend-task.md b/docs/develop/extend-task.md
deleted file mode 100644
index df83e57f4..000000000
--- a/docs/develop/extend-task.md
+++ /dev/null
@@ -1,225 +0,0 @@
-# Extend Tasks
-
-You can extend Iguana with your benchmark task, if the Stresstest doesn't fit your needs.
-F.e. you may want to check systems if they answer correctly rather than stresstest them.
-
-You will need to create your own task either in the Iguana code itself or by using Iguana as a library.
-Either way start by extending the AbstractTask.
-
-```java
-package org.benchmark
-
-@Shorthand("MyBenchmarkTask")
-public class MyBenchmarkTask extend AbstractTask {
-
-}
-
-```
-
-You will need to override some functions. For now include them and go through them step by step
-
-```java
-package org.benchmark
-
-@Shorthand("MyBenchmarkTask")
-public class MyBenchmarkTask extend AbstractTask {
-
- //Your constructor(s)
- public MyBenchmarkTask(Integer timeLimit, ArrayList workers, LinkedHashMap queryHandler) throws FileNotFoundException {
- }
-
-
- //Meta Data (which will be added in the resultsfile)
- @Override
- public void addMetaData() {
- super.addMetaData();
- }
-
- //Initializing
- @Override
- public void init(String[] ids, String dataset, Connection connection) {
- super.init(ids, dataset, connection);
- }
-
- //Your actual Task
- @Override
- public void execute() {
- }
-
-
- //Closing the benchmark, freeing some stuff etc.
- @Override
- public void close() {
- super.close();
- }
-}
-
-```
-
-
-## Constructor and Configuration
-
-Let's start with the Constructor.
-The YAML benchmark configuration will provide you the constructor parameters.
-
-Imagine you want to have three different parameters.
-The first one should provide an integer (e.g. the time limit of the task)
-The second one should provide a list of objects (e.g. a list of integers to use)
-The third parameter should provide a map of specific key-value pairs.
-
-You can set this up by using the following parameters:
-
-```java
-public MyBenchmarkTask(Integer param1, ArrayList param2, LinkedHashMap param3) throws FileNotFoundException {
- //TODO whatever you need to do with the parameters
-}
-```
-
-Then Your configuration may look like the following
-
-```yaml
-...
- className: "MyBenchmarkTask"
- configuration:
- param1: 123
- param2:
- - "1"
- - "2"
- param3:
- val1: "abc"
- val2: 123
-
-```
-
-The parameters will then be matched by their names to the names of the parameters of your constructor, allowing multiple constructors
-
-These are the three types you can represent in a Yaml configuration.
-* Single Values
-* Lists of Objects
-* Key-Value Pairs
-
-
-## Add Meta Data
-
-If you want to add Meta Data to be written in the results file do the following,
-
-Let noOfWorkers a value you already set.
-
-```java
- /**
- * Add extra Meta Data
- */
- @Override
- public void addMetaData() {
- super.addMetaData();
-
- Properties extraMeta = new Properties();
- extraMeta.put("noOfWorkers", noOfWorkers);
-
- //Adding them to the actual meta data
- this.metaData.put(COMMON.EXTRA_META_KEY, extraMeta);
- }
-
-```
-
-Then the resultsfile will contain all the mappings you put in extraMeta.
-
-## Initialize the Task
-
-You may want to initialize your task, set some more values, start something in the background etc. etc.
-
-You will be provided the `suiteID`, `experimentID` and the `taskID` in the `ids` array, as well as the name of the dataset
-and the connection currently beeing benchmarked.
-
-
-```java
- @Override
- public void init(String[] ids, String dataset, Connection connection) {
- super.init(ids, dataset, connection);
- //ADD YOUR CODE HERE
- }
-```
-
-The ids, the dataset and the connection will be set in the `AbstractTask` which you can simply access by using `this.connection` for example.
-
-## Execute
-
-Now you can create the actual benchmark task you want to use.
-
-
-```java
- @Override
- public void execute() {
- //ADD YOUR CODE HERE
- }
-```
-
-Be aware that if you are using the `workers` implemented in Iguana, you need to stop them after your benchmark using the `worker.stopSending()` method.
-
-## Close
-
-If you need to close some streams at the end of your benchmark task, you can do that in the `close` function.
-
-Simply override the existing one and call the super method and implement what you need.
-
-```java
- @Override
- public void close() {
- super.close();
- }
-```
-
-## Full overview
-
-```java
-package org.benchmark
-
-@Shorthand("MyBenchmarkTask")
-public class MyBenchmarkTask extend AbstractTask {
-
- private Integer param1;
- private ArrayList param2;
- private LinkedHashMap param3;
-
- //Your constructor(s)
- public MyBenchmarkTask(Integer param1, ArrayList param2, LinkedHashMap param3) throws FileNotFoundException {
-
- this.param1=param1;
- this.param2=param2;
- this.param3=param3;
-
- }
-
-
- //Meta Data (which will be added in the resultsfile)
- @Override
- public void addMetaData() {
- super.addMetaData();
-
- Properties extraMeta = new Properties();
- extraMeta.put("noOfWorkers", noOfWorkers);
-
- //Adding them to the actual meta data
- this.metaData.put(COMMON.EXTRA_META_KEY, extraMeta);
- }
-
- @Override
- public void init(String[] ids, String dataset, Connection connection) {
- super.init(ids, dataset, connection);
- //ADD YOUR CODE HERE
- }
-
- @Override
- public void execute() {
- //ADD YOUR CODE HERE
- }
-
-
- //Closing the benchmark, freeing some stuff etc.
- @Override
- public void close() {
- super.close();
- }
-}
-
-```
diff --git a/docs/develop/extend-workers.md b/docs/develop/extend-workers.md
deleted file mode 100644
index c85f838aa..000000000
--- a/docs/develop/extend-workers.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# Extend Workers
-
-If the implemented workers aren't sufficient you can create your own one.
-
-Start by extending the `AbstractWorker`
-
-```java
-package org.benchmark.workers
-
-@Shorthand("MyWorker")
-public class MyWorker extends AbstractWorker{
-
-
- //Setting the next query to be benchmarked in queryStr and queryID
- public void getNextQuery(StringBuilder queryStr, StringBuilder queryID) throws IOException{
-
- }
-
-
- //Executing the current benchmark query
- public void executeQuery(String query, String queryID){
-
- }
-
-}
-```
-
-These are the only two functions you need to implement, the rest is done by the `AbstractWorker`.
-
-You can override more functions, please consider looking into the javadoc for that.
-
-## Constructor
-
-The constructor parameters will be provided the same way the Task get's the parameters, thus simply look at [Extend Task](../extend-task).
-
-## Get the next query
-
-The benchmark task should create and initialize the benchmark queries and will set them accordingly to the worker.
-
-You can access these queries using the `queryFileList` array.
-Each element consists of one query set, containing the queryID/name and a list of one to several queries.
-
-In the following we will choose the next query set, counted by `currentQueryID` and use a random query of this.
-
-```java
-
- @Override
- public void getNextQuery(StringBuilder queryStr, StringBuilder queryID) throws IOException {
- // get next Query File and next random Query out of it.
- QuerySet currentQuery = this.queryFileList[this.currentQueryID++];
- queryID.append(currentQuery.getName());
-
- int queriesInSet = currentQuery.size();
- int queryLine = queryChooser.nextInt(queriesInSet);
- queryStr.append(currentQuery.getQueryAtPos(queryLine));
-
- // If there is no more query(Pattern) start from beginning.
- if (this.currentQueryID >= this.queryFileList.length) {
- this.currentQueryID = 0;
- }
-
- }
-```
-
-Thats it.
-
-This exact method is implemented in the `AbstractRandomQueryChooserWorker` class and instead of extend the `AbstractWorker` class, you can also extend this and spare your time.
-However if you need another way like only executing one query and if there are no mery queries to test end the worker you can do so:
-
-```java
-
- @Override
- public void getNextQuery(StringBuilder queryStr, StringBuilder queryID) throws IOException {
- // If there is no more query(Pattern) start from beginning.
- if (this.currentQueryID >= this.queryFileList.length) {
- this.stopSending();
- }
-
-
- // get next Query File and the first Query out of it.
- QuerySet currentQuery = this.queryFileList[this.currentQueryID++];
- queryID.append(currentQuery.getName());
-
- int queriesInSet = currentQuery.size();
- queryStr.append(currentQuery.getQueryAtPos(0));
-
- }
-```
-
-## Execute the current query
-
-Now you can execute the query against the current connection (`this.con`).
-
-As this is up to you how to do that, here is an example implementation for using HTTP Get.
-
-```java
-@Override
- public void executeQuery(String query, String queryID) {
- Instant start = Instant.now();
-
- try {
- String qEncoded = URLEncoder.encode(query, "UTF-8");
- String addChar = "?";
- if (con.getEndpoint().contains("?")) {
- addChar = "&";
- }
- String url = con.getEndpoint() + addChar + parameter+"=" + qEncoded;
- HttpGet request = new HttpGet(url);
- RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(timeOut.intValue())
- .setConnectTimeout(timeOut.intValue()).build();
-
- if(this.responseType != null)
- request.setHeader(HttpHeaders.ACCEPT, this.responseType);
-
- request.setConfig(requestConfig);
- CloseableHttpClient client = HttpClients.createDefault();
- CloseableHttpResponse response = client.execute(request, getAuthContext(con.getEndpoint()));
-
- // method to process the result in background
- super.processHttpResponse(queryID, start, client, response);
-
- } catch (Exception e) {
- LOGGER.warn("Worker[{{ '{{}}' }} : {{ '{{}}' }}]: Could not execute the following query\n{{ '{{}}' }}\n due to", this.workerType,
- this.workerID, query, e);
- super.addResults(new QueryExecutionStats(queryID, COMMON.QUERY_UNKNOWN_EXCEPTION, durationInMilliseconds(start, Instant.now())));
- }
- }
-```
-
diff --git a/docs/develop/how-to-start.md b/docs/develop/how-to-start.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/develop/maven.md b/docs/develop/maven.md
deleted file mode 100644
index c030b301f..000000000
--- a/docs/develop/maven.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Use Iguana as a Maven dependency
-
-Iguana provides 3 packages
-
-**iguana.commons** which consists of some helper classes.
-
-**iguana.resultprocessor** which consists of metrics and the result storage workflow
-
-and **iguana.corecontroller** which contains the tasks, the workers, the query handlers, and the overall Iguana workflow
-
-to use one of these packages in your maven project add the following repository to your pom:
-
-```xml
-
- iguana-github
- Iguana Dice Group repository
- https://maven.pkg.github.com/dice-group/Iguana
-
-```
-
-Afterwards add the package you want to add using the following,
-
-for the core controller, which will also include the result processor as well as the commons.
-
-```xml
-
- org.aksw
- iguana.corecontroller
- ${iguana-version}
-
-```
-
-for the result processor which will also include the commons.
-
-```xml
-
- org.aksw
- iguana.resultprocessor
- ${iguana-version}
-
-```
-
-or for the commons.
-
-```xml
-
- org.aksw
- iguana.commons
- ${iguana-version}
-
-```
diff --git a/docs/develop/overview.md b/docs/develop/overview.md
deleted file mode 100644
index 3dcb93fd6..000000000
--- a/docs/develop/overview.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Development Overview
-
-Iguana is open source and available at Github [here](https://github.com/dice-group/Iguana).
-There are two main options to work on Iguana.
-
-* Fork the git repository and work directly on Iguana
-* or use the [Iguana Maven Packages](https://github.com/orgs/dice-group/packages?repo_name=IGUANA) as a library
-
-Iguana is a benchmark framework which can be extended to fit your needs.
-
-## Extend
-
-There are several things you can extend in Iguana.
-
-* Tasks - Add your benchmark task
-* Workers - Your system won't work with HTTP GET or POST, or work completely different? Add your specific worker.
-* Query Handling - You do not use Plain Text queries or SPARQL? Add your query handler.
-* Language - Want more statistics about your specific queries? The result size isn't accurate? add your language support
-* Result Storage - Don't want to use RDF? Add your own solution to store the benchmark results.
-* Metrics - The metrics won't fit your needs? Add your own.
-
-## Bugs
-
-For bugs please open an issue at our [Github Issue Tracker](https://github.com/dice-group/Iguana/issues)
-
-
diff --git a/docs/download.md b/docs/download.md
deleted file mode 100644
index 08d8a3390..000000000
--- a/docs/download.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Download
-
-## Prerequisites
-
-You need to have Java 11 or higher installed.
-
-
-In Ubuntu you can do this by
-```bash
-sudo apt-get install java
-```
-
-## Download
-
-Please download the latest release at [https://github.com/dice-group/IGUANA/releases/latest](https://github.com/dice-group/IGUANA/releases/latest)
-
-The zip file contains 3 files.
-
-* iguana-{{ release_version }}.jar
-* example-suite.yml
-* start-iguana.sh
-
-The example-suite.yml is a valid benchmark configuration which you can adjust to your needs using the [Configuration](../usage/configuration) wiki.
diff --git a/docs/index.md b/docs/index.md
deleted file mode 100644
index 06543a855..000000000
--- a/docs/index.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## Welcome to the Iguana documentation!
-
-
-
-This documentation will help you benchmark your HTTP endpoints (such as your Triple store) using Iguana and help you extend Iguana to your needs.
-It is split into three parts
-
-* General
-* Quick Start Guide
-* Usage
-* Development
-
-In **General** you will find a bit of information of what Iguana is and what it's capable of.
-
-In the **Quick Start Guide** you will find how to download and start Iguana as well how to quickly configure your first simple benchmark using Iguana.
-
-In **Usage** you will find everything on how to execute a benchmark with Iguana and how to configure the benchmark to your needs.
-It further provides details on what tests Iguana is capable of.
-A Tutorial will finally guide you through all steps broadly which you can use as a quick start.
-
-In **Development** you will find everything you need to know in case that Iguana isn't sufficient for your needs. It shows how to extend Iguana to use your metrics or your specific benchmark test
-
-
-
-Have exciting Evaluations!
diff --git a/docs/quick-config.md b/docs/quick-config.md
deleted file mode 100644
index b498b74df..000000000
--- a/docs/quick-config.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Quickly Configure Iguana
-
-Here we will setup a quick configuration which will benchmark one triple store (e.g. apache jena fuseki) using one simulated user.
-We assume that your triple store (or whatever HTTP GET endpoint you want to use) is running and loaded with data.
-For now we assume that the endpoint is at `http://localhost:3030/ds/sparql` and uses GET with the parameter `query`
-
-Further on the benchmark should take 10 minutes (or 60.000 ms) and uses plain text queries located in `queries.txt`.
-
-If you do not have created some queries yet, use these for example
-
-```sparql
-SELECT * {?s ?p ?o}
-SELECT * {?s ?p ?o} LIMIT 10
-SELECT * {?s ?o}
-```
-
-and save them to `queries.txt`.
-
-
-Your results will be written as an N-Triple file to `first-benchmark-results.nt`
-
-The following configuration works with these demands.
-
-```yaml
-# you can ignore this for now
-datasets:
- - name: "Dataset"
-
-#Your connection
-connections:
- - name: "Fuseki"
- # Change this to your actual endpoint you want to use
- endpoint: "http://localhost:3030/ds/sparql"
-
-# The benchmark task
-tasks:
- - className: "Stresstest"
- configuration:
- # 10 minutes (time Limit is in ms)
- timeLimit: 600000
- # we are using plain text queries
- queryHandler:
- className: "InstancesQueryHandler"
-
- # create one SPARQL Worker (it's basically a HTTP get worker using the 'query' parameter
- # it uses the queries.txt file as benchmark queries
- workers:
- - threads: 1
- className: "SPARQLWorker"
- queriesFile: "queries.txt"
-
-# tell Iguana where to save your results to
-storages:
- - className: "NTFileStorage"
- configuration:
- fileName: "first-benchmark-results.nt"
-```
-
-
-For more information on the confguration have a look at [Configuration](../usage/configuration/)
diff --git a/docs/run-iguana.md b/docs/run-iguana.md
deleted file mode 100644
index 809f5f533..000000000
--- a/docs/run-iguana.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Start a Benchmark
-
-Start Iguana with a benchmark suite (e.g the example-suite.yml) either using the start script
-
-```bash
-./start-iguana.sh example-suite.yml
-```
-
-To set JVM options, you can use `$IGUANA_JVM`
-
-For example to let Iguana use 4GB of RAM you can set the `IGUANA_JVM` as follows
-```bash
-export IGUANA_JVM=-Xmx4g
-```
-
-and start as above.
-
-
-
-or using the jar with java 11 as follows
-
-
-```bash
-java -jar iguana-corecontroller-{{ release_version }}.jar example-suite.yml
-```
-
diff --git a/docs/shorthand-mapping.md b/docs/shorthand-mapping.md
deleted file mode 100644
index e54e3132b..000000000
--- a/docs/shorthand-mapping.md
+++ /dev/null
@@ -1,32 +0,0 @@
-| Shorthand | Class Name |
-|----------|-------|
-| Stresstest | `org.aksw.iguana.cc.tasks.impl.Stresstest` |
-|----------|-------|
-| InstancesQueryHandler | `org.aksw.iguana.cc.query.impl.InstancesQueryHandler` |
-| DelimInstancesQueryHandler | `org.aksw.iguana.cc.query.impl.DelimInstancesQueryHandler` |
-| PatternQueryHandler | `org.aksw.iguana.cc.query.impl.PatternQueryHandler` |
-|----------|-------|
-| lang.RDF | `org.aksw.iguana.cc.lang.impl.RDFLanguageProcessor` |
-| lang.SPARQL | `org.aksw.iguana.cc.lang.impl.SPARQLLanguageProcessor` |
-| lang.SIMPLE | `org.aksw.iguana.cc.lang.impl.ThrowawayLanguageProcessor` |
-|----------|-------|
-| SPARQLWorker | `org.aksw.iguana.cc.worker.impl.SPARQLWorker` |
-| UPDATEWorker | `org.aksw.iguana.cc.worker.impl.UPDATEWorker` |
-| HttpPostWorker | `org.aksw.iguana.cc.worker.impl.HttpPostWorker` |
-| HttpGetWorker | `org.aksw.iguana.cc.worker.impl.HttpGetWorker` |
-| CLIWorker | `org.aksw.iguana.cc.worker.impl.CLIWorker` |
-| CLIInputWorker | `org.aksw.iguana.cc.worker.impl.CLIInputWorker` |
-| CLIInputFileWorker | `org.aksw.iguana.cc.worker.impl.CLIInputFileWorker` |
-| CLIInputPrefixWorker | `org.aksw.iguana.cc.worker.impl.CLIInputPrefixWorker` |
-| MultipleCLIInputWorker | `org.aksw.iguana.cc.worker.impl.MultipleCLIInputWorker` |
-|----------|-------|
-| NTFileStorage | `org.aksw.iguana.rp.storages.impl.NTFileStorage` |
-| RDFFileStorage | `org.aksw.iguana.rp.storages.impl.RDFFileStorage` |
-| TriplestoreStorage | `org.aksw.iguana.rp.storages.impl.TriplestoreStorage` |
-|----------|-------|
-| QPS | `org.aksw.iguana.rp.metrics.impl.QPSMetric` |
-| AvgQPS | `org.aksw.iguana.rp.metrics.impl.AvgQPSMetric` |
-| NoQ | `org.aksw.iguana.rp.metrics.impl.NoQMetric` |
-| NoQPH | `org.aksw.iguana.rp.metrics.impl.NoQPHMetric` |
-| QMPH | `org.aksw.iguana.rp.metrics.impl.QMPHMetric` |
-| EachQuery | `org.aksw.iguana.rp.metrics.impl.EQEMetric` |
diff --git a/docs/usage/configuration.md b/docs/usage/configuration.md
deleted file mode 100644
index 070cb20f2..000000000
--- a/docs/usage/configuration.md
+++ /dev/null
@@ -1,327 +0,0 @@
-# Configuration
-
-The Configuration explains Iguana how to execute your benchmark. It is divided into 5 categories
-
-* Connections
-* Datasets
-* Tasks
-* Storages
-* Metrics
-
-Additionally a pre and post task script hook can be set.
-
-The configuration has to be either in YAML or JSON. Each section will be detailed out and shows configuration examples. At the end the full configuration will be shown.
-For this we will stick to the YAML format, however the equivalent JSON is also valid and can be parsed by Iguana.
-
-### Connections
-
-Every benchmark suite can execute several connections (e.g. an HTTP endpoint, or a CLI application).
-A connection has the following items
-
-* name - the name you want to give the connection, which will be saved in the results.
-* endpoint - the HTTP endpoint or CLI call.
-* updateEndpoint - If your HTTP endpoint is an HTTP Post endpoint set this to the post endpoint. (optional)
-* user - for authentication purposes (optional)
-* password - for authentication purposes (optional)
-* version - setting the version of the tested triplestore, if set resource URI will be ires:name-version (optional)
-
-To setup an endpoint as well as an updateEndpoint might be confusing at first, but if you to test read and write performance simultanously and how updates might have an impact on read performance, you can set up both.
-
-For more detail on how to setup the CLI call look at [Implemented Workers](../workers). There are all CLI Workers explained and how to set the endpoint such that the application will be run correctly.
-
-Let's look at an example:
-
-```yaml
-connections:
- - name: "System1"
- endpoint: "http://localhost:8800/query"
- version: 1.0-SNAP
- - name: "System2"
- endpoint: "http://localhost:8802/query"
- updateEndpoint: "http://localhost:8802/update"
- user: "testuser"
- password: "secret"
-```
-
-Here we have two connections: System1 and System2. System1 is only setup to use an HTTP Get endpoint at http://localhost:8800/query. System2 however uses authentication and has an update endpoint as well, and thus will be correctly test with updates (POSTs) too.
-
-### Datasets
-
-Pretty straight forward. You might want to test your system with different datasets (e.g. databases, triplestores etc.)
-If you system does not work on different datasets, just add one datasetname like
-
-```yaml
-datasets:
- - name: "DoesNotMatter"
-```
-
-otherwise you might want to benchmark different datasets. Hence you can setup a Dataset Name, as well as file.
-The dataset name will be added to the results, whereas both can be used in the task script hooks, to automatize dataset load into your system.
-
-Let's look at an example:
-
-```yaml
-datasets:
- - name: "DatasetName"
- file: "your-data-base.nt"
- - name: "Dataset2"
-```
-
-### Tasks
-
-A Task is one benchmark Task which will be executed against all connections for all datasets.
-A Task might be a stresstest which we will be using in this example. Have a look at the full configuration of the [Stresstest](../stresstest#Configuration)
-
-The configuration of one Task consists of the following:
-
-* className - The className or [Shorthand](#Shorthand)
-* configuration - The parameters of the task
-
-```yaml
-tasks:
- - className: "YourTask"
- configuration:
- parameter1: value1
- parameter2: "value2"
-```
-
-Let's look at an example:
-
-```yaml
-tasks:
- - className: "Stresstest"
- configuration:
- #timeLimit is in ms
- timeLimit: 3600000
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 2
- className: "SPARQLWorker"
- queriesFile: "queries.txt"
- timeOut: 180000
- - className: "Stresstest"
- configuration:
- noOfQueryMixes: 1
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 2
- className: "SPARQLWorker"
- queriesFile: "queries.txt"
- timeOut: 180000
-```
-
-We configured two Tasks, both Stresstests. The first one will be executed for one hour and uses simple text queries which can be executed right away.
-Further on it uses 2 simulated SPARQLWorkers with the same configuration.
-At this point it's recommend to check out the [Stresstest Configuration](../stresstest#Configuration) in detail for further configuration.
-
-
-### Storages
-
-Tells Iguana how to save your results. Currently Iguana supports two solutions
-
-* NTFileStorage - will save your results into one NTriple File.
-* RDFFileStorage - will save your results into an RDF File (default TURTLE).
-* TriplestoreStorage - Will upload the results into a specified Triplestore
-
-This is optional. The default storage is `NTFileStorage`.
-
-**NTFileStorage** can be setup by just stating to use it like
-
-```yaml
-storages:
- - className: "NTFileStorage"
-```
-However it can be configured to use a different result file name. The default is `results_{DD}-{MM}-{YYYY}_{HH}-{mm}.nt`.
-See example below.
-
-```yaml
-storages:
- - className: "NTFileStorage"
- #optional
- configuration:
- fileName: "results-of-my-benchmark.nt"
-```
-
-The **RDFFileStorage** is similar to the NTFileStorage but will determine the RDF format from the file extension
-To use RDF/XML f.e. you would end the file on .rdf, for TURTLE end it on .ttl
-
-```yaml
-storages:
- - className: "NTFileStorage"
- #optional
- configuration:
- fileName: "results-of-my-benchmark.rdf"
-```
-
-
-
-The **TriplestoreStorage** can be configured as follows:
-
-```yaml
-storages:
- - className: TriplestoreStorage
- configuration:
- endpoint: "http://localhost:9999/sparql"
- updateEndpoint: "http://localhost:9999/update"
-```
-
-if you triple store uses authentication you can set that up as follows:
-
-```yaml
-storages:
- - className: TriplestoreStorage
- configuration:
- endpoint: "http://localhost:9999/sparql"
- updateEndpoint: "http://localhost:9999/update"
- user: "UserName"
- password: "secret"
-```
-
-
-For further detail on how to read the results have a look [here](../results)
-
-
-
-### Metrics
-
-Let's Iguana know what Metrics you want to include in the results.
-
-Iguana supports the following metrics:
-
-* Queries Per Second (QPS)
-* Average Queries Per Second (AvgQPS)
-* Query Mixes Per Hour (QMPH)
-* Number of Queries successfully executed (NoQ)
-* Number of Queries per Hour (NoQPH)
-* Each query execution (EachQuery) - experimental
-
-For more detail on each of the metrics have a look at [Metrics](../metrics)
-
-Let's look at an example:
-
-```yaml
-metrics:
- - className: "QPS"
- - className: "AvgQPS"
- - className: "QMPH"
- - className: "NoQ"
- - className: "NoQPH"
-```
-
-In this case we use all the default metrics which would be included if you do not specify `metrics` in the configuration at all.
-However you can also just use a subset of these like the following:
-
-```yaml
-metrics:
- - className: "NoQ"
- - className: "AvgQPS"
-```
-
-For more detail on how the results will include these metrics have a look at [Results](../results).
-
-### Task script hooks
-
-To automatize the whole benchmark workflow, you can setup a script which will be executed before each task, as well as a script which will be executed after each task.
-
-To make it easier, the script can get the following values
-
-* dataset.name - The current dataset name
-* dataset.file - The current dataset file name if there is anyone
-* connection - The current connection name
-* connection.version - The current connection version, if no version is set -> {{ '{{connection.version}}' }}
-* taskID - The current taskID
-
-
-You can set each one of them as an argument using brackets like `{{ '{{connection}}' }}`.
-Thus you can setup scripts which will start your system and load it with the correct dataset file beforehand and stop the system after every task.
-
-However these script hooks are completely optional.
-
-Let's look at an example:
-
-```yaml
-preScriptHook: "/full/path/{{ '{{connection}}' }}-{{ '{{connection.version}}' }}/load-and-start.sh {{ '{{dataset.file}}' }}"
-postScriptHook: "/full/path/{{ '{{connection}}' }}/stop.sh"
-
-```
-
-### Full Example
-
-```yaml
-connections:
- - name: "System1"
- endpoint: "http://localhost:8800/query"
- - name: "System2"
- endpoint: "http://localhost:8802/query"
- updateEndpoint: "http://localhost:8802/update"
- user: "testuser"
- password: "secret"
-
-datasets:
- - name: "DatasetName"
- file: "your-data-base.nt"
- - name: "Dataset2"
-
-tasks:
- - className: "Stresstest"
- configuration:
- #timeLimit is in ms
- timeLimit: 3600000
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 2
- className: "SPARQLWorker"
- queriesFile: "queries.txt"
- timeOut: 180000
- - className: "Stresstest"
- configuration:
- noOfQueryMixes: 1
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 2
- className: "SPARQLWorker"
- queriesFile: "queries.txt"
- timeOut: 180000
-
-preScriptHook: "/full/path/{{ '{{connection}}' }}/load-and-start.sh {{ '{{dataset.file}}' }}"
-postScriptHook: "/full/path/{{ '{{connection}}' }}/stop.sh"
-
-
-metrics:
- - className: "QMPH"
- - className: "QPS"
- - className: "NoQPH"
- - className: "NoQ"
- - className: "AvgQPS"
-
-storages:
- - className: "NTFileStorage"
- #optional
- - configuration:
- fileName: "results-of-my-benchmark.nt"
-```
-
-
-### Shorthand
-
-A shorthand is a short name for a class in Iguana which can be used in the configuration instead of the complete class name:
-e.g. instead of
-
-```yaml
-storages:
- - className: "org.aksw.iguana.rp.storage.impl.NTFileStorage"
-```
-
-you can use the shortname NTFileStorage:
-
-```yaml
-storages:
- - className: "NTFileStorage"
-```
-
-
-For a full map of the Shorthands have a look at [Shorthand-Mapping](../../shorthand-mapping)
diff --git a/docs/usage/getting-started.md b/docs/usage/getting-started.md
deleted file mode 100644
index 21ce6045e..000000000
--- a/docs/usage/getting-started.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## What is Iguana
-
-Iguana is a HTTP and CLI read/write performance benchmark framework suite.
-It can stresstest HTTP get and post endpoints as well as CLI applications using a bunch of simulated users which will bombard the endpoint using queries.
-Queries can be anything. SPARQL, SQL, Text and anything else you can fit in one line.
-
-### What can be benchmarked
-
-Iguana is capable of benchmarking and stresstesting the following applications
-
-* HTTP GET and POST endpoint (e.g. Triple Stores, REST Services, Question Answering endpoints)
-* CLI Applications which either
- * exit after every query
- * or awaiting input after each query
-
-### What Benchmarks are possible
-
-Every simulated User (named Worker in the following) gets a set of queries.
-These queries have to be saved in one file, whereas each query is one line.
-Hence everything you can fit in one line (e.g a SPARQL query, a text question, an RDF document) can be used as a query and a set of these queries represent the benchmark.
-Iguana will then let every Worker execute these queries against the endpoint.
-
-
-## Download
-
-Please download the latest release at [https://github.com/dice-group/IGUANA/releases/latest](https://github.com/dice-group/IGUANA/releases/latest)
-
-The zip file contains 3 files.
-
-* iguana-corecontroller-x.y.z.jar
-* example-suite.yml
-* start.sh
-
-The example-suite.yml is a valid benchmark configuration which you can adjust to your needs using the [Configuration](Configuration) wiki.
-
-## Start a Benchmark
-
-Start Iguana with a benchmark suite (e.g the example-suite.yml) either using the start script
-
-```bash
-./start-iguana.sh example-suite.yml
-```
-
-or using java 11 if you want to give Iguana more RAM or in general set JVM options.
-
-```bash
-java -jar iguana-corecontroller-3.3.2.jar example-suite.yml
-```
-
diff --git a/docs/usage/languages.md b/docs/usage/languages.md
deleted file mode 100644
index 18af1e166..000000000
--- a/docs/usage/languages.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Supported Languages
-
-The Language tag is set to assure that the result size returned by the benchmarked system is correctly read and that result can give a little extra query statistics.
-
-Currently two languages are implemented, however you can use `lang.SPARQL` or simply ignore it all the way.
-If they are not in `SPARQL` the query statistics will be just containing the query text and the result size will be read as if each returned line were one result.
-
-Additionaly a SIMPLE language tag is added which parses nothing and sets the result size as the content length of the results.
-
-If you work with results which have a content length >=2GB please use `lang.SIMPLE`, as `lang.SPARQL` and `lang.RDF` cannot work with results >=2GB at the moment.
-
-The 3 languages are:
-
-* `lang.SPARQL`
-* `lang.RDF`
-* `lang.SIMPLE`
diff --git a/docs/usage/metrics.md b/docs/usage/metrics.md
deleted file mode 100644
index ff5abc4af..000000000
--- a/docs/usage/metrics.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Implemented Metrics
-
-Every metric will be calculated globally (for one Experiment Task) and locally (for each Worker)
-Hence you can just analyze the overall metrics or if you want to look closer, you can look at each worker.
-
-## NoQ
-
-The number of successfully executed Queries
-
-## QMPH
-
-The number of executed Query Mixes Per Hour
-
-## NoQPH
-
-The number of successfully executed Number of Queries Per Hour
-
-## QPS
-
-For each query the `queries per second`, the `total time` in ms (summed up time of each execution), the no of `succeeded` and `failed` executions and the `result size` will be saved.
-Additionaly will try to tell how many times a query failed with what reason. (`timeout`, `wrong return code` e.g. 400, or `unknown`)
-
-Further on the QPS metrics provides a penalized QPS which penalizes queries which will fail.
-As some systems who cannot resolve a query just returns an error code and thus can have a very high score, even though they could only handle a few queries it would be rather unfair to the compared systems. Thus we introduced the penalty QPS. It is calculated the same as the QPS score, but for each failed query it uses the penalty instead of the actual time the failed query took.
-
-The default is set to the timeOut of the task.
-However you can override it as follows:
-
-```yaml
-metrics:
- - className: "QPS"
- configuration:
- #in MS
- penality: 10000
-```
-
-## AvgQPS
-
-The average of all queries per second.
-Also adding a penalizedAvgQPS. Default penalty is timeOut, can be overwritten as follows:
-
-```yaml
-metrics:
- - className: "AvgQPS"
- confiugration:
- # in ms
- penalty: 10000
-```
-
-## EachQuery
-
-Will save every query execution. (Experimental)
-
diff --git a/docs/usage/queries.md b/docs/usage/queries.md
deleted file mode 100644
index 74b8edfef..000000000
--- a/docs/usage/queries.md
+++ /dev/null
@@ -1,115 +0,0 @@
-# Supported Queries
-
-There are currently two query types supported:
-
-* plain text queries
-* SPARQL pattern queries
-
-## Plain Text Queries
-
-This can be anything: SPARQL, SQL, a whole book if you need to.
-The only limitation is that it has to fit in one line per query. If that isn't possible use the [Multiple Line Plain Text Queries](#multiple-line-plain-text-queries).
-Every query can be executed as is.
-
-This can be set using the following:
-
-```yaml
-...
- queryHandler:
- className: "InstancesQueryHandler"
-```
-
-## SPARQL Pattern Queries
-
-This only works for SPARQL Queries at the moment.
-The idea came from the DBpedia SPARQL Benchmark paper from 2011 and 2012.
-
-Instead of SPARQL queries as they are, you can set variables, which will be exchanged with real data.
-Hence Iguana can create thousands of queries using a SPARQL pattern query.
-
-A pattern query might look like the following:
-```sparql
-SELECT * {?s rdf:type %%var0%% ; %%var1%% %%var2%%. %%var2%% ?p ?o}
-```
-
-This query in itself cannot be send to a triple store, however we can exchange the variables using real data.
-Thus we need a reference endpoint (ideally) containing the same data as the dataset which will be tested.
-
-This query will then be exchanged to
-```sparql
-SELECT ?var0 ?var1 ?var2 {?s rdf:type ?var0 ; ?var1 ?var2. ?var2 ?p ?o} LIMIT 2000
-```
-
-and be queried against the reference endpoint.
-
-For each result (limited to 2000) a query instance will be created.
-
-This will be done for every query in the benchmark queries.
-All instances of these query patterns will be subsummed as if they were one query in the results.
-
-This can be set using the following:
-
-```yaml
-...
- queryHandler:
- className: "PatternQueryHandler"
- endpoint: "http://your-reference-endpoint/sparql"
-```
-
-or
-
-```yaml
-...
- queryHandler:
- className: "PatternQueryHandler"
- endpoint: "http://your-reference-endpoint/sparql"
- limit: 4000
-```
-
-## Multiple Line Plain Text Queries
-
-Basically like Plain Text Queries. However allows queries which need more than one line.
-You basically seperate queries using a delimiter line.
-
-Let's look at an example, where the delimiter line is simply an empty line (this is the default)
-
-```
-QUERY 1 {
-still query 1
-}
-
-QUERY 2 {
-still Query2
-}
-```
-
-however if you set the delim=`###` for example the file has to look like:
-
-```
-QUERY 1 {
-still query 1
-}
-###
-QUERY 2 {
-still Query2
-}
-```
-
-The delimiter query handler can be set as follows
-
-
-```yaml
-...
- queryHandler:
- className: "DelimInstancesQueryHandler"
-```
-
-or if you want to set the delimiter line
-
-```yaml
-...
- queryHandler:
- className: "DelimInstancesQueryHandler"
- delim: "###"
-```
-
diff --git a/docs/usage/results.md b/docs/usage/results.md
deleted file mode 100644
index 68faf0ae6..000000000
--- a/docs/usage/results.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# Experiment Results
-
-
-
-## Fundamentals
-
-The results are saved into RDF.
-For those who don't know what RDF is, it is best described as a way to represent a directed graph.
-The according query language is called SPARQL.
-The graph schema of an iguana result is shown above, where as each node represents a class object containg several annotations.
-
-To retrieve all TaskIDs you can do the following:
-
-```sparql
-PREFIX rdf:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-
-SELECT ?taskID {
- ?suiteID rdf:type iont:Suite .
- ?suiteID iprop:experiment ?expID .
- ?expID iprop:task ?taskID .
-}
-```
-
-Let's look at an example to clarify how to request the global NoQ metric for a taskID you already know.
-Let's assume the taskID is `123/1/1`
-
-
-```sparql
-PREFIX rdf:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-
-SELECT ?noq {
- ires:123/1/1 iprop:NoQ ?noq
-}
-```
-
-If you want to get all the local worker NoQ metrics do the following:
-
-```sparql
-PREFIX rdf:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-
-SELECT ?workerID ?noq {
- ires:123/1/1 iprop:workerResult ?workerID
- ?workerID iprop:NoQ ?noq
-}
-```
-
-However if you just want to see the global NoQ metric for all taskIDs in your results do the following:
-
-```sparql
-PREFIX rdf:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-
-SELECT ?taskID ?noq {
- ?suiteID rdf:type iont:Suite .
- ?suiteID iprop:experiment ?expID .
- ?expID iprop:task ?taskID .
- ?taskID iprop:NoQ ?noq.
-}
-```
-
-Instead of the NoQ metric you can do this for all other metrics, except `QPS`.
-
-To retrieve `QPS` look above in the results schema and let's look at an example. Let's assume the taskID is `123/1/1` again.
-You can retrieve the global qps values (seen above in ExecutedQueries, e.g `QPS`, `succeeded` etc.) as follows,
-
-```sparql
-PREFIX rdf:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-
-SELECT ?executedQuery ?qps ?failed ?resultSize {
- ires:123/1/1 iprop:query ?executedQuery .
- ?executedQuery iprop:QPS ?qps.
- ?executedQuery iprop:failed ?failed .
- ?executedQuery iprop:resultSize ?resultSize .
-}
-```
-This will get you the QPS value, the no. of failed queries and the result size of the query.
-
-
-Further on you can show the dataset and connection names.
-
-```
-PREFIX rdf:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-PREFIX rdfs:
-
-SELECT ?taskID ?datasetLabel ?connectionLabel ?noq {
- ?suiteID rdf:type iont:Suite .
- ?suiteID iprop:experiment ?expID .
- ?expID iprop:dataset ?dataset .
- ?dataset rdfs:label ?datasetLabel
- ?expID iprop:task ?taskID .
- ?taskID iprop:connection ?connection.
- ?connection rdfs:label ?connectionLabel .
- ?taskID iprop:NoQ ?noq.
-}
-
-```
-
-This query will show a table containing for each task, the taskID, the dataset name, the connection name and the no. of queries succesfully executed.
-
-## SPARQL Query statistics
-
-If you were using SPARQL queries as your benchmark queries you can add addtional further statistics of a query, such as: does the query has a FILTER.
-
-```sparql
-PREFIX rdf:
-PREFIX rdfs:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-
-SELECT ?executedQuery ?qps ?hasFilter ?queryText {
- ires:123/1/1 iprop:query ?executedQuery .
- ?executedQuery iprop:QPS ?qps.
- ?executedQuery iprop:queryID ?query .
- ?query iprop:filter ?hasFilter .
- ?query rdfs:label ?queryText .
-}
-```
-
-This provides the qps value, if the SPARQL query has a filter and the actual query string.
-
-
-## Ontology
-
-The results ontology (description of what each property and class means) can be found [here](http://iguana-benchmark.eu/ontology/3.3.2/iguana.owl)
-
-
-
-## Adding LSQ analyzation
-
-If you're using SPARQL and want some more indepth analysation of the query statistics, you can use [LSQ](https://github.com/AKSW/LSQ) to do so.
-Iguana will add an `owl:sameAs` link between the SPARQL queries used in your benchmark and the equivalent LSQ query links.
-
-Hence you can run the performance measurement using Iguana and the query analyzation using LSQ independently and combine both results afterwards
diff --git a/docs/usage/stresstest.md b/docs/usage/stresstest.md
deleted file mode 100644
index ea4c6302b..000000000
--- a/docs/usage/stresstest.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# Stresstest
-
-Iguanas implemented Stresstest benchmark task tries to emulate a real case scenario under which an endpoint or application is under high stress.
-As in real life endpoints might get multiple simultaneous request within seconds, it is very important to verify that you application can handle this.
-
-The stresstest emulates users or applications which will bombard the endpoint using a set of queries for a specific amount of time or a specific amount of queries executed.
-Each simulated user is called Worker in the following.
-As you might want to test read and write performance or just want to emulate different user behaviour, the stresstest allows to configure several workers.
-Every worker configuration can additionaly be started several times, hence if you want one configuration executed multiple times, you can simply tell Iguana to run this worker configuration the specified amount of time.
-However to assure that the endpoint can't just cache the repsonse of the first request of a query, every worker starts at a pre determined random query, meaning that the single worker will always start at that query to assure fairness in benchmark comparisons, while every worker will start at a different query.
-
-## Configuration
-
-To configure this task you have to first tell Iguana to use the implemented task like the following:
-
-```yaml
-tasks:
- - className: "Stresstest"
-```
-
-Further on you need to configure the Stresstest using the configuration parameter like:
-
-```yaml
-tasks:
- - className: "Stresstest"
- configuration:
- timeLimit: 600000
- ...
-```
-
-As an end restriction you can either use `timeLimit` which will stop the stresstest after the specified amount in ms or you can set `noOfQueryMixes` which stops every worker after they executed the amount of queries in the provided query set.
-
-Additionaly to either `timeLimit` or `noOfQueryMixes` you can set the following parameters
-
-* queryHandler
-* workers
-* warmup (optional)
-
-### Query Handling
-
-The queryHandler parameter let's the stresstest know what queries will be used.
-Normally you will need the `InstancesQueryHandler` which will use plain text queries (could be SQL, SPARQL, a whole RDF document). The only restriction is that each query has to be in one line.
-
-You can set the query handler like the following:
-```yaml
-tasks:
- - className: "Stresstest"
- queryHandler:
- className: "InstancesQueryHandler"
- ...
-```
-
-To see which query handlers are supported see [Supported Queries](../queries/)
-
-### Workers (simulated Users)
-
-Further on you have to add which workers to use.
-As described above you can set different worker configurations.
-Let's look at an example:
-```yaml
- - className: "Stresstest"
- timeLimit: 600000
- workers:
- - threads: 4
- className: "SPARQLWorker"
- queriesFile: "/path/to/your/queries.txt"
- - threads: 16
- className: "SPARQLWorker"
- queriesFile: "/other/queries.txt"
- fixedLatency: 5000
-```
-
-In this example we have two different worker configurations we want to use. The first want will create 4 `SPARQLWorker`s using queries at `/path/to/your/queries.txt` with any latencym thus every query will be executed immediatly after another.
-The second worker configuration will execute 16 `SPARQLWorker`s using queries at `/other/queries.txt` using a fixed waiting time of `5000ms` between each query.
-Hence every worker will execute their queries independently from each other but will wait 5s after each of their query execution before executing the next one.
-This configuration may simulate that we have a few Users requesting your endpoint locally (e.g. some of your application relying on your database) and several users querying your endpoint from outside the network where we would have network latency and other interferences which we will try to simulate with 5s.
-
-A full list of supported workers and their parameters can be found at [Supported Workers](../workers)
-
-In this example our Stresstest would create 20 workers, which will simultaenously request the endpoint for 60000ms (10 minutes).
-
-### Warmup
-
-Additionaly to these you can optionally set a warmup, which will aim to let the system be benchmarked under a normal situation (Some times a database is faster when it was already running for a bit)
-The configuration is similar to the stresstest itself you can set a `timeLimit` (however not a certain no of query executions), you can set different `workers`, and a `queryHandler` to use.
-If you don't set the `queryHandler` parameter the warmup will simply use the `queryHandler` specified in the Stresstest itself.
-
-You can set the Warmup as following:
-```yaml
-tasks:
- - className: "Stresstest"
- warmup:
- timeLimit: 600000
- workers:
- ...
- queryHandler:
- ...
-```
-
-That's it.
-A full example might look like this
-
-```yaml
-tasks:
- - className: "Stresstest"
- configuration:
- # 1 hour (time Limit is in ms)
- timeLimit: 3600000
- # warmup is optional
- warmup:
- # 10 minutes (is in ms)
- timeLimit: 600000
- # queryHandler could be set too, same as in the stresstest configuration, otherwise the same queryHandler will be use.
- # workers are set the same way as in the configuration part
- workers:
- - threads: 1
- className: "SPARQLWorker"
- queriesFile: "queries_warmup.txt"
- timeOut: 180000
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 16
- className: "SPARQLWorker"
- queriesFile: "queries_easy.txt"
- timeOut: 180000
- - threads: 4
- className: "SPARQLWorker"
- queriesFile: "queries_complex.txt"
- fixedLatency: 100
-```
-
-## References
-
-* [Supported Queries](../queries/)
-* [Supported Workers](../workers)
diff --git a/docs/usage/tutorial.md b/docs/usage/tutorial.md
deleted file mode 100644
index bd9fc0313..000000000
--- a/docs/usage/tutorial.md
+++ /dev/null
@@ -1,342 +0,0 @@
-# Tutorial
-
-In this tutorial we will go through one benchmark using two systems, two datasets and one Stresstest.
-
-We are using the following
-
-* Iguana v3.0.2
-* Apache Jena Fuseki 3
-* Blazegraph
-
-## Download
-
-First lets create a working directory
-
-```bash
-mkdir myBenchmark
-cd myBenchmark
-```
-
-Now let's download all required systems and Iguana.
-
-Starting with Iguana
-```bash
-wget https://github.com/dice-group/IGUANA/releases/download/v3.0.2/iguana-3.0.2.zip
-unzip iguana-3.0.2.zip
-```
-
-Now we will download Blazegraph
-
-```bash
-mkdir blazegraph && cd blazegraph
-wget https://downloads.sourceforge.net/project/bigdata/bigdata/2.1.5/blazegraph.jar?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fbigdata%2Ffiles%2Fbigdata%2F2.1.5%2Fblazegraph.jar%2Fdownload%3Fuse_mirror%3Dmaster%26r%3Dhttps%253A%252F%252Fwww.blazegraph.com%252Fdownload%252F%26use_mirror%3Dnetix&ts=1602007009
-cd ../
-```
-
-At last we just need to download Apache Jena Fuseki and Apache Jena
-
-```bash
-mkdir fuseki && cd fuseki
-wget https://downloads.apache.org/jena/binaries/apache-jena-3.16.0.zip
-unzip apache-jena-3.16.0.zip
-
-wget https://downloads.apache.org/jena/binaries/apache-jena-fuseki-3.16.0.zip
-unzip apache-jena-fuseki-3.16.0.zip
-```
-
-Finally we have to download our datasets.
-We use two small datasets from scholarly data.
-The ISWC 2010 and the ekaw 2012 rich dataset.
-
-```
-mkdir datasets/
-cd datasets
-wget http://www.scholarlydata.org/dumps/conferences/alignments/iswc-2010-complete-alignments.rdf
-wget http://www.scholarlydata.org/dumps/conferences/alignments/ekaw-2012-complete-alignments.rdf
-cd ..
-```
-
-
-That's it.
-Let's setup blazegraph and fuseki.
-
-## Setting Up Systems
-
-To simplify the benchmark workflow we will use the pre and post script hook, in which we will load the current system and after the benchmark stop the system.
-
-### Blazegraph
-
-First let's create the script files
-
-```bash
-cd blazegraph
-touch load-and-start.sh
-touch stop.sh
-```
-
-The `load-and-start.sh` script will start blazegraph and use curl to POST our dataset.
-In our case the datasets are pretty small, hence the loading time is minimal.
-Otherwise it would be wise to load the dataset beforehand, backup the `blazegraph.jnl` file and simply exchanging the file in the pre script hook.
-
-For now put this into the script `load-and-start.sh`
-
-```bash
-#starting blazegraph with 4 GB ram
-cd ../blazegraph && java -Xmx4g -server -jar blazegraph.jar &
-
-#load the dataset file in, which will be set as the first script argument
-curl -X POST H 'Content-Type:application/rdf+xml' --data-binary '@$1' http://localhost:9999/blazegraph/sparql
-```
-
-Now edit `stop.sh` and adding the following:
-
-```
-pkill -f blazegraph
-```
-
-Be aware that this kills all blazegraph instances, so make sure that no other process which includes the word blazegraph is running.
-
-finally get into the correct working directory again
-```bash
-cd ..
-```
-
-### Fuseki
-
-Now the same for fuseki:
-
-```bash
-cd fuseki
-touch load-and-start.sh
-touch stop.sh
-```
-
-The `load-and-start.sh` script will load the dataset into a TDB directory and start fuseki using the directory.
-
-Edit the script `load-and-start.sh` as follows
-
-```bash
-cd ../fuseki
-# load the dataset as a tdb directory
-apache-jena-3.16.0/bin/tdbloader2 --loc DB $1
-
-# start fuseki
-apache-jena-fuseki-3.16.0/fuseki-server --loc DB /ds &
-
-```
-
-To assure fairness and provide Fuseki with 4GB as well edit `apache-jena-fuseki-3.16.0/fuseki-server` and go to the last bit exchange the following
-
-```
-JVM_ARGS=${JVM_ARGS:--Xmx1200M}
-```
-
-to
-
-```
-JVM_ARGS=${JVM_ARGS:--Xmx4G}
-```
-
-Now edit `stop.sh` and adding the following:
-
-```
-pkill -f fuseki
-```
-
-Be aware that this kills all Fuseki instances, so make sure that no other process which includes the word fuseki is running.
-
-finally get into the correct working directory again
-```bash
-cd ..
-```
-
-## Benchmark queries
-
-We need some queries to benchmark.
-
-For now we will just use 3 simple queryies
-```
-SELECT * {?s ?p ?o}
-SELECT * {?s ?p ?o} LIMIT 10
-SELECT * {?s ?o}
-```
-
-save this to `queries.txt`
-
-
-
-## Creating the Benchmark Configuration
-
-Now let's create the Iguana benchmark configuration.
-Create a file called `benchmark-suite.yml`
-
-```bash
-touch benchmark-suite.yml
-```
-
-Add the following subscections to this file, or simply go to [#Full Configuration](full-configuration) and add the whole piece to it.
-
-Be aware that the configuration will be started on directory level below our working directory and thus paths will use `../` to get the correct path.
-
-### Datasets
-
-We have two datasets, the ekaw 2012 and the iswc 2010 datasets.
-Let's name them as such and set the file path, s.t. the script hooks can use the file paths.
-
-```yaml
-datasets:
- - name: "ekaw-2012"
- file: "../datasets/ekaw-2012-complete-alignments.rdf"
- - name: "iswc-2010"
- file: "../datasets/iswc-2010-complete-alignments.rdf"
-```
-
-### Connections
-
-We have two connections, blazegraph and fuseki with their respective endpoint at them as following:
-
-```yaml
-connections:
- - name: "blazegraph"
- endpoint: "http://localhost:9999/blazegraph/sparql"
- - name: "fuseki"
- endpoint: "http://localhost:3030/ds/sparql"
-```
-
-### Task script hooks
-
-To assure that the correct triple store will be loaded with the correct dataset add the following pre script hook `../{{ '{{connection}}' }}/load-and-start.sh {{ '{{dataset.file}}' }}`
-`{{ '{{connection}}' }}` will be set to the current benchmarked connection name (e.g. `fuseki`) and the `{{ '{{dataset.file}}' }}` will be set to the current dataset file path.
-
-For example the start script of fuseki is located at `fuseki/load-and-start.sh`.
-
-Further on add the `stop.sh` script as the post-script hook, assuring that the store will be stopped after each task
-
-This will look like this:
-
-```yaml
-pre-script-hook: "../{{ '{{connection}}' }}/load-and-start.sh {{ '{{dataset.file}}' }}"
-post-script-hook: "../{{ '{{connection}}' }}/stop.sh
-```
-
-### Task configuration
-
-We want to stresstest our stores using 10 minutes (60.000 ms)for each dataset connection pair.
-We are using plain text queries (`InstancesQueryHandler`) and want to have two simulated users querying SPARQL queries.
-The queries file is located at our working directory at `queries.txt`. Be aware that we start Iguana one level below, which makes the correct path `../queries.txt`
-
-To achieve this restrictions add the following to your file
-
-```yaml
-tasks:
- - className: "Stresstest"
- configuration:
- timeLimit: 600000
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 2
- className: "SPARQLWorker"
- queriesFile: "../queries.txt"
-```
-
-### Result Storage
-
-Let's put the results as an NTriple file and for smootheness of this tutorial let's put it into the file `my-first-iguana-results.nt`
-
-Add the following to do this.
-
-```yaml
-storages:
- - className: "NTFileStorage"
- configuration:
- fileName: "my-first-iguana-results.nt"
-```
-
-### Full configuration
-
-```yaml
-datasets:
- - name: "ekaw-2012"
- file: "../datasets/ekaw-2012-complete-alignments.rdf"
- - name: "iswc-2010"
- file: "../datasets/iswc-2010-complete-alignments.rdf"
-
-connections:
- - name: "blazegraph"
- endpoint: "http://localhost:9999/blazegraph/sparql"
- - name: "fuseki"
- endpoint: "http://localhost:3030/ds/sparql"
-
-pre-script-hook: "../{{ '{{connection}}' }}/load-and-start.sh {{ '{{dataset.file}}' }}"
-post-script-hook: "../{{ '{{connection}}' }}/stop.sh
-
-tasks:
- - className: "Stresstest"
- configuration:
- timeLimit: 600000
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 2
- className: "SPARQLWorker"
- queriesFile: "../queries.txt"
-
-storages:
- - className: "NTFileStorage"
- configuration:
- fileName: "my-first-iguana-results.nt"
-```
-
-## Starting Benchmark
-
-Simply use the previous created `benchmark-suite.yml` and start with
-
-```bash
-cd iguana/
-./start-iguana.sh ../benchmark-suite.yml
-```
-
-Now we wait for 40 minutes until the benchmark is finished.
-
-## Results
-
-As previously shown, our results will be shown in `my-first-iguana-results.nt`.
-
-Load this into a triple store of your choice and query for the results you want to use.
-
-Just use blazegraph for example:
-
-```bash
-cd blazegraph
-../load-and-start.sh ../my-first-iguana-results.nt
-```
-
-To query the results go to `http://localhost:9999/blazegraph/`.
-
-An example:
-
-```
-PREFIX rdf:
-PREFIX iprop:
-PREFIX iont:
-PREFIX ires:
-PREFIX rdfs:
-
-SELECT ?taskID ?datasetLabel ?connectionLabel ?noq {
- ?suiteID rdf:type iont:Suite .
- ?suiteID iprop:experiment ?expID .
- ?expID iprop:dataset ?dataset .
- ?dataset rdfs:label ?datasetLabel
- ?expID iprop:task ?taskID .
- ?taskID iprop:connection ?connection.
- ?connection rdfs:label ?connectionLabel .
- ?taskID iprop:NoQ ?noq.
-}
-
-```
-
-This will provide a list of all task, naming the dataset, the connection and the no. of queries which were succesfully executed
-
-We will however not go into detail on how to read the results.
-This can be read at [Benchmark Results](../results/)
diff --git a/docs/usage/workers.md b/docs/usage/workers.md
deleted file mode 100644
index a54794906..000000000
--- a/docs/usage/workers.md
+++ /dev/null
@@ -1,333 +0,0 @@
-# Supported Workers
-
-A Worker is basically just a thread querying the endpoint/application. It tries to emulate a single user/application requesting your system until it should stop.
-In a task (e.g. the [stresstest](../stresstest/)) you can configure several worker configurations which will then be used inside the task.
-
-Every worker configuration can additionaly be started several times, hence if you want one configuration executed multiple times, you can simply tell Iguana to run this worker configuration the specified amount of time.
-However to assure that the endpoint can't just cache the repsonse of the first request of a query, every worker starts at a pre determined random query, meaning that the single worker will always start at that query to assure fairness in benchmark comparisons, while every worker will start at a different query.
-
-There a few workers implemented, which can be seperated into two main categories
-
-* Http Workers
-* CLI Workers
-
-## Http Workers
-
-These Workers can be used to benchmark Http Applications (such as a SPARQL endpoint).
-
-### Http Get Worker
-
-A Http worker using GET requests.
-This worker will use the `endpoint` of the connection.
-
-This worker has several configurations listed in the following table:
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| parameterName | yes | query | the GET paremter to set the query as value to. (see also [Supported Queries](../queries) ) |
-| responseType | yes | | The content type the endpoint should return. Setting the `Accept: ` header |
-| language | yes | lang.SPARQL (plain text) | The language the queries and response are in (e.g. SPARQL). Basically just creates some more statistics (see [Supported Langauges](languages) ) |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-Let's look at an example:
-
-```yaml
- ...
- workers:
- - threads: 1
- className: "HttpGetWorker"
- timeOut: 180000
- parameterName: "text"
-```
-
-This will use one HttpGetWOrker using a timeout of 3 minutes and the get parameter text to request the query through.
-
-### Http Post Worker
-
-A Http worker using POST requests.
-This worker will use the `updateEndpoint` of the connection.
-
-This worker has several configurations listed in the following table:
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| parameterName | yes | query | the GET paremter to set the query as value to. (see also [Supported Queries](../queries) ) |
-| contentType | yes | `text/plain` | The content type of the update queries. Setting the `Content-Type: ` header |
-| responseType | yes | | The content type the endpoint should return. Setting the `Accept: ` header |
-| language | yes | lang.SPARQL (plain text) | The language the queries and response are in (e.g. SPARQL). Basically just creates some more statistics (see [Supported Langauges](languages) ) |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-Let's look at an example:
-
-```yaml
- ...
- workers:
- - threads: 1
- className: "HttpPostWorker"
- timeOut: 180000
-```
-
-This will use one HttpGetWOrker using a timeout of 3 minutes.
-
-### SPARQL Worker
-
-Simply a GET worker but the language parameter is set to `lang.SPARQL`.
-Otherwise see the [Http Get Worker](#http-get-worker) for configuration
-
-An Example:
-```yaml
- ...
- workers:
- - threads: 1
- className: "SPARQLWorker"
- timeOut: 180000
-```
-
-
-### SPARQL UPDATE Worker
-
-Simply a POST worker but specified for SPARQL Updates.
-
-Parameters are :
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| timerStrategy | yes | `NONE` | `NONE`, `FIXED` or `DISTRIBUTED`. see below for explanation. |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-
-The **timerStrategy** parameter let's the worker know how to distribute the updates.
-The fixedLatency and gaussianLatency parameters are not affected, the worker will wait those additionally.
-
-* NONE: the worker just updates each update query after another
-* FIXED: calculating the distribution by `timeLimit / #updates` at the start and waiting the amount between each update. Time Limit will be used of the task the worker is executed in.
-* DISTRIBUTED: calculating the time to wait between two updates after each update by `timeRemaining / #updatesRemaining`.
-
-An Example:
-```yaml
- ...
- workers:
- - threads: 1
- className: "UPDATEWorker"
- timeOut: 180000
- timerStrategy: "FIXED"
-```
-
-
-## CLI Workers
-
-These workers can be used to benchmark a CLI application.
-
-### CLI Worker
-
-This Worker should be used if the CLI application runs a query once and exits afterwards.
-Something like
-```bash
-$ cli-script.sh query
-HEADER
-QUERY RESULT 1
-QUERY RESULT 2
-...
-$
-```
-
-Parameters are :
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-
-An Example:
-```yaml
- ...
- workers:
- - threads: 1
- className: "CLIWorker"
-```
-
-
-### CLI Input Worker
-
-This Worker should be used if the CLI application runs and the query will be send using the Input.
-
-Something like
-```bash
-$ cli-script.sh start
-Your Input: QUERY
-HEADER
-QUERY RESULT 1
-QUERY RESULT 2
-...
-
-Your Input:
-```
-
-Parameters are :
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| initFinished | no | | String which occurs when the application is ready to be requested (e.g. after loading) |
-| queryFinished | no | | String which occurs if the query response finished |
-| queryError | no | | String which occurs when an error during the query execution happend |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-An Example:
-```yaml
- ...
- workers:
- - threads: 1
- className: "CLIInputWorker"
- initFinished: "loading finished"
- queryFinished: "query execution took:"
- queryError: "Error happend during request"
-```
-
-### Multiple CLI Input Worker
-
-
-This Worker should be used if the CLI application runs and the query will be send using the Input and will quit on errors.
-
-Something like
-```bash
-$ cli-script.sh start
-Your Input: QUERY
-HEADER
-QUERY RESULT 1
-QUERY RESULT 2
-...
-
-Your Input: ERROR
-ERROR happend, exiting
-$
-```
-
-To assure a smooth benchmark, the CLI application will be run multiple times instead of once, and if the application quits, the next running process will be used, while in the background the old process will be restarted.
-Thus as soon as an error happend, the benchmark can continue without a problem.
-
-Parameters are :
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| initFinished | no | | String which occurs when the application is ready to be requested (e.g. after loading) |
-| queryFinished | no | | String which occurs if the query response finished |
-| queryError | no | | String which occurs when an error during the query execution happend |
-| numberOfProcesses | yes | 5 | The number of times the application should be started to assure a smooth benchmark. see above. |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-An Example:
-```yaml
- ...
- workers:
- - threads: 1
- className: "MultipleCLIInputWorker"
- initFinished: "loading finished"
- queryFinished: "query execution took:"
- queryError: "Error happend during request"
-```
-
-### CLI Input File Worker
-
-Same as the [Multiple CLI Input Worker](#multiple-cli-input-worker). However the query won't be send to the input but written to a file and the file will be send to the input
-
-Something like
-```bash
-$ cli-script.sh start
-Your Input: file-containg-the-query.txt
-HEADER
-QUERY RESULT 1
-QUERY RESULT 2
-...
-
-```
-
-Parameters are :
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| initFinished | no | | String which occurs when the application is ready to be requested (e.g. after loading) |
-| queryFinished | no | | String which occurs if the query response finished |
-| queryError | no | | String which occurs when an error during the query execution happend |
-| directory | no | | Directory in which the file including the query should be saved. |
-| numberOfProcesses | yes | 5 | The number of times the application should be started to assure a smooth benchmark. see [Multiple CLI Input Worker](#multiple-cli-input-worker). |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-
-An Example:
-```yaml
- ...
- workers:
- - threads: 1
- className: "CLIInputFileWorker"
- initFinished: "loading finished"
- queryFinished: "query execution took:"
- queryError: "Error happend during request"
- directory: "/tmp/"
-```
-
-### CLI Input Prefix Worker
-
-Same as the [Multiple CLI Input Worker](#multiple-cli-input-worker). However the CLI application might need a pre and suffix.
-
-Something like
-```bash
-$ cli-script.sh start
-Your Input: PREFIX QUERY SUFFIX
-HEADER
-QUERY RESULT 1
-QUERY RESULT 2
-...
-
-```
-
-
-Parameters are :
-
-| parameter | optional | default | description |
-| ----- | --- | ----- | --------- |
-| queriesFile | no | | File containg the queries this worker should use. |
-| initFinished | no | | String which occurs when the application is ready to be requested (e.g. after loading) |
-| queryFinished | no | | String which occurs if the query response finished |
-| queryError | no | | String which occurs when an error during the query execution happend |
-| queryPrefix | no | | String to use as a PREFIX before the query. |
-| querySuffix | no | | String to use as a SUFFIX after the query. |
-| numberOfProcesses | yes | 5 | The number of times the application should be started to assure a smooth benchmark. see [Multiple CLI Input Worker](#multiple-cli-input-worker). |
-| timeOut | yes | 180000 (3 minutes) | The timeout in MS after a query should be aborted |
-| fixedLatency | yes | 0 | If the value (in MS) should be waited between each query. Simulating network latency or user behaviour. |
-| gaussianLatency | yes | 0 | A random value between `[0, 2*value]` (in MS) will be waited between each query. Simulating network latency or user behaviour. |
-
-
-An Example:
-```yaml
- ...
- workers:
- - threads: 1
- className: "CLIInputPrefixWorker"
- initFinished: "loading finished"
- queryFinished: "query execution took:"
- queryError: "Error happend during request"
- queryPrefix: "SPARQL"
- querySuffix: ";"
-```
-Will send the following as Input `SPARQL QUERY ;`
diff --git a/docs/usage/workflow.md b/docs/usage/workflow.md
deleted file mode 100644
index 6ec5d42fc..000000000
--- a/docs/usage/workflow.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Workflow
-
-Iguana will first parse configuration and afterwards will execute each task for each connection for each dataset.
-
-Imagine it like the following:
-
-* for each dataset D
- * for each connection C
- * for each task T
- 1. execute pre script hook
- 2. execute task T(D, C)
- 3. collect and calculate results
- 4. write results
- 5. execute post script hook
-
diff --git a/example-suite.yml b/example-suite.yml
index c4290113e..00c50eb5e 100644
--- a/example-suite.yml
+++ b/example-suite.yml
@@ -1,68 +1,108 @@
+# This file showcases the configuration of most IGUANA features.
+
+# Datasets are optional and have no functionality.
datasets:
- name: "DatasetName"
- #optional, will just be set in the pre & post script hooks by using {{dataset.file}}
file: "src/test/resources/dataset.txt"
+
+# Connections that will be used by the workers for the benchmark.
connections:
- name: "Virtuoso7"
- user: "dba"
- password: "dba"
+ authentication:
+ user: "dba"
+ password: "dba"
endpoint: "http://localhost:8890/sparql"
+ dataset: "DatasetName" # optional
- name: "Virtuoso6"
- user: "dba"
- password: "dba"
+ authentication:
+ user: "dba"
+ password: "dba"
endpoint: "http://localhost:8891/sparql"
- name: "Blazegraph"
endpoint: "http://localhost:9999/blazegraph/sparql"
- - name: "Fuseki"
- user: "test"
- endpoint: "http://127.0.0.1:3030/ds/sparql"
+ authentication:
+ user: "user"
+ password: "test"
updateEndpoint: "http://localhost:3030/ds/update"
+ updateAuthentication:
+ user: "updateUser"
+ password: "password"
+# The tasks that will be executed by the benchmark. They will be executed in the order they are defined.
tasks:
- - className: "org.aksw.iguana.cc.tasks.impl.Stresstest"
- configuration:
- # 1 hour (time Limit is in ms)
- timeLimit: 360000
- # warmup is optional
- warmup:
- # 1 minutes (is in ms)
- timeLimit: 600000
- # queryHandler could be set too, same as in the stresstest configuration, otherwise the same queryHandler will be use.
- # workers are set the same way as in the configuration part
- workers:
- - threads: 1
- className: "SPARQLWorker"
- queriesFile: "queries_warmup.txt"
- timeOut: 180000
- queryHandler:
- className: "InstancesQueryHandler"
- workers:
- - threads: 16
- className: "SPARQLWorker"
- queriesFile: "queries_easy.txt"
- timeOut: 180000
- - threads: 4
- className: "SPARQLWorker"
- queriesFile: "queries_complex.txt"
- fixedLatency: 100
- gaussianLatency: 50
- parameterName: "query"
- responseType: "application/sparql-results+json"
+ - type: stresstest # Stresstests are used to test the performance of the system by sending a large number of requests.
+ warmupWorkers: # Warmup workers are used to warm up the system before the actual stresstest.
+ - type: SPARQLProtocolWorker
+ requestType: post update # Send POST requests with application/sparql-update content type to the endpoint.
+ number: 16 # Initialize 16 workers with the same configuration.
+ queries:
+ path: "./example/queries"
+ format: "folder" # Queries are stored in a folder.
+ order: "linear"
+ timeout: 0.02s
+ connection: Virtuoso7
+ parseResults: false
+ completionTarget:
+ number: 50 # Execute each query 50 times.
+ workers:
+ - type: "SPARQLProtocolWorker"
+ number: 16
+ queries:
+ path: "./example/queries.txt"
+ order: "random"
+ seed: 42
+ timeout: 3m
+ connection: Virtuoso7
+ parseResults: false
+ completionTarget:
+ duration: 1000s # Execute the queries for 1000 seconds.
+ requestType: post url-enc query # Send url-encoded POST request to endpoint.
+ - number: 4
+ type: "SPARQLProtocolWorker"
+ connection: Virtuoso7
+ requestType: post url-enc update
+ completionTarget:
+ duration: 1000s
+ queries:
+ path: "./example/queries.txt"
+ timeout: 100s
+ acceptHeader: "application/sparql-results+json" # Accept header for the request.
+ - type: stresstest
+ workers:
+ - type: "SPARQLProtocolWorker"
+ connection: Virtuoso7
+ number: 16
+ requestType: post query
+ queries:
+ path: "./example/queries.txt"
+ timeout: 180s
+ completionTarget:
+ duration: 1000s
+ parseResults: false
+ - number: 4
+ requestType: get query # Send GET request with the query as the parameter to the endpoint.
+ connection: Virtuoso7
+ completionTarget:
+ duration: 1000s
+ type: "SPARQLProtocolWorker"
+ queries:
+ path: "./example/queries.txt"
+ timeout: 100s
+ parseResults: true
+ acceptHeader: "application/sparql-results+json"
-# both are optional and can be used to load and start as well as stop the connection before and after every task
-preScriptHook: "./triplestores/{{connection}}/start.sh {{dataset.file}} {{dataset.name}} {{taskID}}"
-postScriptHook: "./triplestores/{{connection}}/stop.sh"
-
-#optional otherwise the same metrics will be used as default
-metrics:
- - className: "QMPH"
- - className: "QPS"
- - className: "NoQPH"
- - className: "AvgQPS"
- - className: "NoQ"
-
-#optional otherwise an nt file will be used
+# Define how the results will be stored.
storages:
- - className: "NTFileStorage"
- #configuration:
- #fileName: YOUR_RESULT_FILE_NAME.nt
\ No newline at end of file
+ - type: "rdf file"
+ path: "some.ttl"
+ - type: "csv file"
+ directory: "results/"
+ - type: "triplestore"
+ user: "dba"
+ password: "dba"
+ endpoint: "http://localhost:8890/update"
+
+responseBodyProcessors:
+ - contentType: "application/sparql-results+json"
+ threads: 1
+ timeout: 1 min
diff --git a/graalvm/generate-config.sh b/graalvm/generate-config.sh
new file mode 100755
index 000000000..fdd4625f2
--- /dev/null
+++ b/graalvm/generate-config.sh
@@ -0,0 +1,54 @@
+#!/usr/bin/env bash
+
+if [ -z "$GRAALVM_HOME" ]; then
+ echo "The variable GRAALVM_HOME needs to be set to the GraalVM installation directory."
+ exit 1
+fi
+
+SUITE=./graalvm/suite.yml
+TARGET_DIR=./target
+while getopts ":hs:t:" opt; do
+ case ${opt} in
+ h)
+ echo "Usage: $0 [-h] [-s ]"
+ echo " -h: Display this help message."
+ echo " -s : The path to the suite.yml file. Default: ./graalvm/suite.yml"
+ echo " -t : The location of the maven target directory. Default: ./target/"
+ exit 0
+ ;;
+ t)
+ TARGET_DIR=$OPTARG
+ ;;
+ s)
+ SUITE=$OPTARG
+ ;;
+ ?)
+ echo "Invalid option: ${opt}" 1>&2
+ exit 1
+ ;;
+ esac
+done
+
+if [ ! -f "$TARGET_DIR"/iguana.jar ]; then
+ mvn -DskipTests package
+fi
+
+if [ ! -d src/main/resources/META-INF/native-image/ ]; then
+ mkdir -p src/main/resources/META-INF/native-image/
+fi
+
+# Move generated configuration files from tests to the resources
+if [ -f "$TARGET_DIR"/native/agent-output/test/resource-config.json ]; then
+ mv "$TARGET_DIR"/native/agent-output/test/* src/main/resources/META-INF/native-image/
+fi
+
+# Run through multiple different execution paths, so that the tracing agent can generate complete configuration files.
+"$GRAALVM_HOME"/bin/java -agentlib:native-image-agent=config-merge-dir=src/main/resources/META-INF/native-image/ -jar "$TARGET_DIR"/iguana.jar --help > /dev/null
+"$GRAALVM_HOME"/bin/java -agentlib:native-image-agent=config-merge-dir=src/main/resources/META-INF/native-image/ -jar "$TARGET_DIR"/iguana.jar --dry-run -is "$SUITE" > /dev/null
+"$GRAALVM_HOME"/bin/java -agentlib:native-image-agent=config-merge-dir=src/main/resources/META-INF/native-image/ -jar "$TARGET_DIR"/iguana.jar --dry-run "$SUITE" > /dev/null
+
+# there is a bug in the tracing agent that outputs wrong formatted lines in the resource-config.json file (https://github.com/oracle/graal/issues/7985)
+sed 's/\\\\E//g' src/main/resources/META-INF/native-image/resource-config.json | sed 's/\\\\Q//g' > src/main/resources/META-INF/native-image/resource-config.json.tmp
+mv src/main/resources/META-INF/native-image/resource-config.json.tmp src/main/resources/META-INF/native-image/resource-config.json
+
+rm -r ./graalvm/results/
diff --git a/graalvm/generate-profile.sh b/graalvm/generate-profile.sh
new file mode 100755
index 000000000..5960767ed
--- /dev/null
+++ b/graalvm/generate-profile.sh
@@ -0,0 +1,61 @@
+#!/usr/bin/env bash
+
+# Check if the GRAALVM_HOME variable is set
+if [ -z "$GRAALVM_HOME" ]; then
+ echo "The variable GRAALVM_HOME needs to be set to the GraalVM installation directory."
+ exit 1
+fi
+
+# Default value for ARGUMENTS
+ARGUMENTS="--gc=G1 -march=x86-64-v3"
+
+# Parse the command line arguments
+while getopts ":hs:a:" opt; do
+ case ${opt} in
+ h)
+ echo "Usage: $0 [-h] [-s ]"
+ echo " -h: Display this help message."
+ echo " -s : The path to the suite.yml file"
+ echo " -a : The arguments to pass to the native-image command. Default: --gc=G1 -march=x86-64-v3"
+ exit 0
+ ;;
+ s)
+ SUITE=$OPTARG
+ ;;
+ a)
+ ARGUMENTS="$OPTARG"
+ ;;
+ ?)
+ echo "Invalid option: $OPTARG" 1>&2
+ exit 1
+ ;;
+ esac
+done
+
+# Check if suite argument was given
+printf ""
+if [ -z "$SUITE" ]; then
+ echo "Argument -s is required."
+ exit 1
+fi
+
+# Instrument the application
+"$GRAALVM_HOME"/bin/native-image --pgo-instrument "$ARGUMENTS" -jar ./target/iguana.jar -o "./target/iguana-4.0.0-instrumented"
+if [ $? -ne 0 ]; then
+ echo "Error while instrumenting the application."
+ exit 1
+fi
+
+# Generate the profile
+./target/iguana-4.0.0-instrumented -XX:ProfilesDumpFile=custom.iprof "$SUITE"
+if [ $? -ne 0 ]; then
+ echo "Error while generating the profile."
+ exit 1
+fi
+
+# Compile the application with the profile
+"$GRAALVM_HOME"/bin/native-image --pgo=custom.iprof "$ARGUMENTS" -jar ./target/iguana.jar -o "./target/iguana-4.0.0-pgo"
+if [ $? -ne 0 ]; then
+ echo "Error while compiling the application."
+ exit 1
+fi
diff --git a/graalvm/queries.txt b/graalvm/queries.txt
new file mode 100644
index 000000000..b3a425249
--- /dev/null
+++ b/graalvm/queries.txt
@@ -0,0 +1 @@
+placeholder
\ No newline at end of file
diff --git a/graalvm/suite.yml b/graalvm/suite.yml
new file mode 100644
index 000000000..243127d1f
--- /dev/null
+++ b/graalvm/suite.yml
@@ -0,0 +1,88 @@
+datasets:
+ - name: "DatasetName"
+ file: "src/test/resources/dataset.txt"
+
+connections:
+ - name: "Blazegraph"
+ version: "1.1.1"
+ dataset: "DatasetName"
+ endpoint: "http://localhost:9999/blazegraph/sparql"
+ authentication:
+ user: "user"
+ password: "test"
+ updateEndpoint: "http://localhost:3030/ds/update"
+ updateAuthentication:
+ user: "updateUser"
+ password: "password"
+
+storages:
+ - type: "rdf file"
+ path: "graalvm/results/some.ttl"
+ - type: "csv file"
+ directory: "graalvm/results/"
+ - type: "triplestore"
+ endpoint: "http://localhost:9999/blazegraph/sparql"
+ user: "user"
+ password: "test"
+ baseUri: "http://example.org"
+
+responseBodyProcessors:
+ - contentType: "application/sparql-results+json"
+ threads: 1
+
+metrics:
+ - type: "AES"
+ - type: "EachQuery"
+ - type: "QPS"
+ - type: "AvgQPS"
+ - type: "NoQ"
+ - type: "NoQPH"
+ - type: "QMPH"
+ - type: "PAvgQPS"
+ penalty: 100
+ - type: "PQPS"
+ penalty: 100
+
+
+tasks:
+ # 1 hour (time Limit is in ms)
+ - type: stresstest
+ warmupWorkers:
+ # 1 minutes (is in ms)
+ - type: SPARQLProtocolWorker
+ number: 1
+ queries:
+ path: "./graalvm/queries.txt"
+ format: "separator"
+ separator: ";"
+ caching: true
+ order: "random"
+ seed: 123
+ lang: "SPARQL"
+ timeout: 2s
+ connection: Blazegraph
+ completionTarget:
+ duration: 1s
+ acceptHeader: "application/sparql-results+json"
+ requestType: get query
+ parseResults: true
+ workers:
+ - type: "SPARQLProtocolWorker"
+ number: 1
+ queries:
+ path: "./graalvm/queries.txt"
+ timeout: 3m
+ connection: Blazegraph
+ completionTarget:
+ duration: 1s
+ requestType: get query
+ acceptHeader: "application/sparql-results+json"
+ - number: 1
+ type: "SPARQLProtocolWorker"
+ connection: Blazegraph
+ completionTarget:
+ number: 1
+ queries:
+ path: "./graalvm/queries.txt"
+ timeout: 100s
+ acceptHeader: "application/sparql-results+json"
diff --git a/iguana.commons/README b/iguana.commons/README
deleted file mode 100644
index 5ca5f7d2a..000000000
--- a/iguana.commons/README
+++ /dev/null
@@ -1,46 +0,0 @@
-CONTENTS OF THIS FILE
----------------------
-
-* Introduction
-* Requirements
-* Installation
-* Configuration
-* Links
-
-
-INTRODUCTION
-------------
-
-The Commons module of Iguana will be used
-to serve as methods and utils which all or several modules of Iguana needs
-
-Bugs can be submitted at https://github.com/AKSW/IGUANA/issues
-Please refer to the Module as following "[Commons] your message"
-
-
-REQUIREMENTS
-------------
-
-The Commons is not a standalone module.
-
-
-INSTALLATION
-------------
-
-The Commons is not a standalone module.
-
-
-CONFIGURATION
--------------
-
-The Commons is not a standalone module.
-
-
-LINKS
------
-
-* Project Site: http://iguana-benchmark.eu
-
-* Github Site: http://github.com/AKSW/IGUANA
-
-* Bug Tracker: http://github.com/AKSW/IGUANA/issues
diff --git a/iguana.commons/pom.xml b/iguana.commons/pom.xml
deleted file mode 100644
index 07ae01253..000000000
--- a/iguana.commons/pom.xml
+++ /dev/null
@@ -1,162 +0,0 @@
-
- 4.0.0
-
- org.aksw
- iguana-parent
- ${revision}
-
- iguana.commons
- Iguana Commons
- Iguana Common Classes and Methods
-
-
- AGPLv3 or later
- https://www.gnu.org/licenses/agpl-3.0.html
-
-
-
-
- Lixi Conrads
- lixiconrads@gmail.com
-
- Former Developer
-
- Dice Research Group
- https://dice-research.org
-
-
-
- Dice Research Group
- https://dice-research.org
-
-
- GitHub Issue Management
- https://github.com/dice-group/iguana/issues
-
- https://dice-research.org/IGUANA
-
-
- 11
- 2.17.1
- 3.16.0
- UTF-8
- 11
- 11
-
-
-
-
- junit
- junit
- 4.13.1
- test
-
-
- commons-configuration
- commons-configuration
- 1.10
-
-
- org.apache.commons
- commons-exec
- 1.3
-
-
- org.apache.logging.log4j
- log4j-slf4j-impl
- ${log4j.version}
-
-
- org.apache.logging.log4j
- log4j-api
- ${log4j.version}
-
-
- org.apache.logging.log4j
- log4j-core
- ${log4j.version}
-
-
- org.apache.logging.log4j
- log4j-1.2-api
- ${log4j.version}
-
-
- org.simpleframework
- simple
- 5.1.6
-
-
- org.reflections
- reflections
- 0.9.9
-
-
-
-
-
- github
- GitHub dice-group Apache Maven Packages
- https://maven.pkg.github.com/dice-group/IGUANA
-
-
-
-
-
-
-
-
- org.jacoco
- jacoco-maven-plugin
- 0.8.6
-
-
- prepare-agent
-
- prepare-agent
-
-
-
- report
- prepare-package
-
- report
-
-
-
- post-unit-test
- test
-
- report
-
-
-
-
- target/jacoco.exec
-
- target/jacoco-ut
-
-
-
-
-
- org.apache.maven.plugins
- maven-compiler-plugin
- 3.8.1
-
-
- 11
- UTF-8
-
- -parameters
-
-
- **/log4j2.yml
-
-
-
-
-
-
-
diff --git a/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/Nullable.java b/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/Nullable.java
deleted file mode 100644
index 3d11e9dd7..000000000
--- a/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/Nullable.java
+++ /dev/null
@@ -1,12 +0,0 @@
-package org.aksw.iguana.commons.annotation;
-
-import java.lang.annotation.*;
-
-/**
- * Lets the TypeFactory know that the Parameter can be null and thus be ignored.
- */
-@Documented
-@Retention(RetentionPolicy.RUNTIME)
-@Target(ElementType.PARAMETER)
-public @interface Nullable {
-}
diff --git a/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/ParameterNames.java b/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/ParameterNames.java
deleted file mode 100644
index ceae9f810..000000000
--- a/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/ParameterNames.java
+++ /dev/null
@@ -1,14 +0,0 @@
-package org.aksw.iguana.commons.annotation;
-
-import java.lang.annotation.*;
-
-/**
- * Uses provided names in the order of the constructor parameters, instead of the constructor parameter names for the TypeFactory
- */
-@Retention(RetentionPolicy.RUNTIME)
-@Target(ElementType.CONSTRUCTOR)
-@Inherited
-public @interface ParameterNames {
-
- String[] names() default "";
-}
diff --git a/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/Shorthand.java b/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/Shorthand.java
deleted file mode 100644
index ee19817ca..000000000
--- a/iguana.commons/src/main/java/org/aksw/iguana/commons/annotation/Shorthand.java
+++ /dev/null
@@ -1,14 +0,0 @@
-package org.aksw.iguana.commons.annotation;
-
-import java.lang.annotation.*;
-
-/**
- * Sets a short name to be used in the TypedFactory instead of the whole class name
- */
-@Documented
-@Retention(RetentionPolicy.RUNTIME)
-@Target(ElementType.TYPE)
-public @interface Shorthand {
-
- String value();
-}
diff --git a/iguana.commons/src/main/java/org/aksw/iguana/commons/constants/COMMON.java b/iguana.commons/src/main/java/org/aksw/iguana/commons/constants/COMMON.java
deleted file mode 100644
index 3851193a1..000000000
--- a/iguana.commons/src/main/java/org/aksw/iguana/commons/constants/COMMON.java
+++ /dev/null
@@ -1,113 +0,0 @@
-package org.aksw.iguana.commons.constants;
-
-/**
- * Constants several modules need
- *
- * @author f.conrads
- *
- */
-public class COMMON {
-
- /*
- * COMMON CONSTANTS
- */
-
-
- /**
- * The key for the experiment task ID in the properties received from the core
- */
- public static final String EXPERIMENT_TASK_ID_KEY = "taskID";
-
- /**
- * The key for the experiment ID in the properties received from the core
- */
- public static final String EXPERIMENT_ID_KEY = "expID";
-
- /**
- * The key for suite ID in the properties received from the core
- */
- public static final String SUITE_ID_KEY = "suiteID";
-
-
- /**
- * The key for starting an experiment task. Must be in the receiving properties
- */
- public static final String RECEIVE_DATA_START_KEY = "startExperimentTask";
-
- /**
- * The key for ending an experiment task. Must be in the receiving properties
- */
- public static final String RECEIVE_DATA_END_KEY = "endExperimentTask";
-
-
- /**
- * Key in the properties receiving from the core to start an experiment
- * as well as internal rp metrics key
- */
- public static final String METRICS_PROPERTIES_KEY = "metrics";
-
-
-
- /**
- * TP2RP query time key
- */
- public static final String RECEIVE_DATA_TIME = "resultTime";
-
- /**
- * TP2RP (Controller2RP) query success key
- */
- public static final String RECEIVE_DATA_SUCCESS = "resultSuccess";
-
- /**
- * The number of Queries in the particular experiment
- * will be used in the meta data.
- */
- public static final String NO_OF_QUERIES = "noOfQueries";
-
-
-
- public static final String QUERY_ID_KEY = "queryID";
-
- public static final String CONNECTION_ID_KEY = "connID";
-
- public static final String DATASET_ID_KEY = "datasetID";
-
- public static final String EXTRA_META_KEY = "extraMeta";
-
- public static final String EXTRA_IS_RESOURCE_KEY = "setIsResource";
-
- public static final String QUERY_STRING = "queryString";
-
- public static final String DOUBLE_RAW_RESULTS = "doubleRawResults";
-
- public static final String SIMPLE_TRIPLE_KEY = "cleanTripleText";
-
- public static final String QUERY_STATS = "queryStats";
-
- public static final Object RECEIVE_DATA_SIZE = "resultSize";
-
- public static final String QUERY_HASH = "queryHash";
-
- public static final String WORKER_ID = "workerID";
-
- /* Various status codes to denote the status of query execution and to prepare QueryExecutionStats object */
- public static final Long QUERY_UNKNOWN_EXCEPTION = 0L;
-
- public static final Long QUERY_SUCCESS = 1L;
-
- public static final Long QUERY_SOCKET_TIMEOUT = -1L;
-
- public static final Long QUERY_HTTP_FAILURE = -2L;
-
- public static final String EXPERIMENT_TASK_CLASS_ID_KEY = "actualTaskClass" ;
-
- public static final String BASE_URI = "http://iguana-benchmark.eu";
-
-
- public static final String RES_BASE_URI = BASE_URI+"/resource/";
- public static final String PROP_BASE_URI = BASE_URI+"/properties/";
- public static final String CLASS_BASE_URI = BASE_URI+"/class/";
- public static final String PENALTY = "penalty";
- public static final String CONNECTION_VERSION_KEY = "connectionVersion";
- public static final String EXPERIMENT_TASK_NAME_KEY = "taskName";
-}
diff --git a/iguana.commons/src/main/java/org/aksw/iguana/commons/factory/TypedFactory.java b/iguana.commons/src/main/java/org/aksw/iguana/commons/factory/TypedFactory.java
deleted file mode 100644
index 8d62570f0..000000000
--- a/iguana.commons/src/main/java/org/aksw/iguana/commons/factory/TypedFactory.java
+++ /dev/null
@@ -1,296 +0,0 @@
-/**
- *
- */
-package org.aksw.iguana.commons.factory;
-
-import org.aksw.iguana.commons.annotation.Nullable;
-import org.aksw.iguana.commons.annotation.ParameterNames;
-import org.aksw.iguana.commons.reflect.ShorthandMapper;
-import org.slf4j.Logger;
-import org.slf4j.LoggerFactory;
-
-import java.lang.reflect.Constructor;
-import java.lang.reflect.InvocationTargetException;
-import java.lang.reflect.Parameter;
-import java.util.*;
-
-
-/**
- * Factory for a Type.
- * Creates an Object from Constructor and Constructor Arguments
- *
- * @author f.conrads
- * @param The Type which should be created
- *
- */
-public class TypedFactory {
-
- private static final Logger LOGGER = LoggerFactory
- .getLogger(TypedFactory.class);
-
- private String getClassName(String className){
- Map map = ShorthandMapper.getInstance().getShortMap();
- if(map.containsKey(className)){
- return map.get(className);
- }
- return className;
- }
-
-
- /**
- * Will create a T Object from a Constructor Object created by the
- * class name and the constructor arguments, be aware that all arguments
- * must be Strings in the constructor.
- *
- *
- * @param className
- * The Class Name of the Implemented T Object
- * @param constructorArgs
- * constructor arguments (must be Strings), can be safely null
- * @return The T Object created by the Constructor using the
- * constructor args
- */
- @SuppressWarnings("unchecked")
- public T create(String className, Object[] constructorArgs){
- Object[] constructorArgs2 = constructorArgs;
- if (constructorArgs2 == null) {
- constructorArgs2 = new Object[0];
- }
- Class[] stringClass = new Class[constructorArgs2.length];
- for(int i=0;i[] constructorClasses) {
-
- Object[] constructorArgs2 = constructorArgs;
-
- if (className == null) {
- return null;
- }
- Class extends T> clazz;
- try {
- clazz = (Class extends T>) ClassLoader
- .getSystemClassLoader().loadClass(className);
- } catch (ClassNotFoundException e1) {
- LOGGER.error("Could not load Object (name: " + className
- + ")", e1);
- return null;
- }
-
-
- if (constructorArgs2 == null) {
- constructorArgs2 = new Object[0];
- }
- if(constructorClasses==null){
- constructorClasses = new Class[constructorArgs2.length];
- for (int i = 0; i < constructorClasses.length; i++) {
- constructorClasses[i] = String.class;
- }
- }
-
- try {
- Constructor extends T> constructor = clazz
- .getConstructor(constructorClasses);
- return constructor.newInstance(constructorArgs2);
- } catch (InstantiationException | IllegalAccessException
- | IllegalArgumentException | InvocationTargetException
- | NoSuchMethodException | SecurityException e) {
- LOGGER.error("Could not initialize class " + clazz.getName()
- + " with constructor.", e);
- return null;
- }
- }
-
-
- /**
- * Uses the parameter Names and types of a constructor to find the best fitting constructor
- *
- * Only works with jvm -paramaters, otherwise use createAnnotated and annotate the constructors with ParameterNames and set names to the paramater names
- * like
- * . @ParameterNames(names={"a", "b"})
- * public Constructor(String a, Object b){...}
- *
- * @param className The Class Name of the Implemented T Object
- * @param map key-value pair, whereas key represents the parameter name, where as value will be the value of the instantiation
- * @return The instantiated object or null no constructor was found
- */
- public T create(String className, Map