DOC: Supported Virtual Applications

• Virtual Application can be grouped on 4 major types:

  • Transactional: Represents typical commercial multi-tier applications. These are characterized by having large numbers of small transactions, being I/O bound (normally at the database tier) and limited horizontal scalability.
    • Examples: SPECJbb and DayTrader
  • Data-intensive distributed applications (Big Data): large transactions – normally data transformations over large amounts of pre-produced data – and good horizontal scalability.
    • Examples: Hadoop and Giraph
  • High Performance Computing (HPC): large transactions, network (latency) bound and variable horizontal scalability (typically only loosely-coupled HPC applications are horizontally scalable)
    • Examples: HPC Challenge benchmark suite (HPCC)
  • Synthetic benchmark applications: simple benchmarks that generate a heavy demand on a particular resource (e.g., processing, memory, networking, storage).
    • Example: coremark benchmark (processor-intensive only).

• The list of supported Virtual Applications can be obtained with the command typelist on the CLI.

• The details of a particular Virtual Application are displayed with the command typeshow (vapp type) on the CLI.

  • Example: (TESTCLOUD) typeshow cassandra_ycsb

    The AI with the type cassandra_ycsb has the following configuration on experiment (Cloud TESTSIMCLOUD) : description: Deploys a Cassandra cluster (N seed nodes and M data nodes), plus one VM running the YCSB benchmark. This single VM sends requests to all seed node VMs simultaneously.

    - LOAD_PROFILE possible values: "workload"{a-f} (for a proper description, consult the section "Core Workloads" on the YCSB documentation)

    - LOAD_LEVEL meaning: number of threads on YCSB (parameter -threads).

    - LOAD_DURATION meaning: not used, a run ends when all YCSB operations (default is 1000) are finished.

    - COMMENT: One of the "Big Data" Workloads. One of the two Virtual Applications types selected for the SPECCloud 2014 v1.0 benchmark. When new seed nodes are added (after an "airesize") the VM running YCSB will automatically direct requests to these new seed nodes.

    sut: ycsb->1_x_seed->1_x_cassandra

    reported_metrics: bandwidth,throughput,latency,datagen_time,datagen_size

    load_balancer_supported: False

    resize_supported: True

    regenerate_data: True

    load_profile: workloadd

    load_level: 1

    load_duration: 60

    load_manager_role: ycsb

    metric_aggregator_role: ycsb

    capture_role: ycsb

    cassandra_setup1: cb_restart_node.sh

    seed_setup1: cb_restart_seed.sh

    ycsb_setup2: cb_setup_ycsb.sh

    start: cb_ycsb.sh

    cassandra_resize1: cb_modify_node.sh

    load_generator_role: ycsb

    read_ratio: workloaddefault

    update_ratio: workload default