DOC: Supported Virtual Applications

Transactional Virtual Applications

Type	Topology	Profiles	Data Generation	Load Generator	Load Level	Reported Metrics	Authors
DayTrader1	1Xclient_daytrader V 1xWAS V 1XDB2	single ("default")	Pre-generated	iwlengine	Number of simultaneous clients	Latency and Throughput	Marcio Silva, Michael Hines
Tradelite2	1Xclient_tradelite V 1xWAS	single ("default")	Generated for each new load level	iwlengine	Number of simultaneous clients	Latency and Throughput	Marcio Silva, Scott Trent
LOST3	1Xclient_lost V 1xlostfront V 1Xlostback	single ("default")	Generated for each new load level	autobench	Number of simultaneous clients	Latency and Throughput	Michael Hines
SPECWeb4	1Xclient_specweb V 1xspecwebfront V 1Xspecwebback	single ("default")	Pre-generated	specweb	TBD	Latency and Throughput	Michael Hines
SPECJbb5	1Xspecjbb	single ("default")	Generated for each new load level	specjbb	TBD	Latency and Throughput	Marcio Silva, Michael Dawson

Comments:

1. Daytrader

• Daytrader has two pre-generated database sizes: 400 MB, by setting the attribute "TRADEDB_SIZE = small" and 6 GB, by setting the attribute "TRADEDB_SIZE = large".
• When using the "large" database, the number of users and quotes on the database can be increase by changing the attributes "NR_QUOTES=6000000" (default is 40000) and "NR_USERS=3000000" (default is 15000)
• The database can be placed on a ramdisk inside the DB2 VM, by setting the attribute "DB2_ON_RAMDISK = $True"
• Daytrader can be used in "scale-out" mode, by having a load balancer in front of multiple WAS VMs. To do so, changing the attribute "LOAD_BALANCER = $True". The number of WAS VMs can the be controlled by changing the attribute "SUT=client_daytrader->3_x_was->db2

2. Tradelite

• Contrary to DayTrader, the database is rebuilt each time a new load level is selected, using the default configurations on application.
• Usually Tradelite uses a Derby database, running co-located within the WAS VM. A 3rd tier, containing an actual DB2 database running on a separate VM can be added by setting the attribute "SUT=client_tradelite->was->db2"

Big Data Virtual Applications

Type	Topology	Profiles	Data Generation	Load Generator	Load Level	Reported Metrics	Authors
Hadoop4	1Xhadoopmaster V 3xhadoopslave	terasort	Generated once during deployment	terasort	Size of the dataset to be sorted	Latency	Marcio Silva, Yoonseo Choi

Synthetic Virtual Applications

Type	Topology	Profiles	Data Generation	Load Generator	Load Level	Reported Metrics	Authors
netperf5	1Xnetclient V 1xnetserver	TCP_STREAM TCP_MAERTS TCP_RR TCP_CC TCP_CRR UDP_STREAM UDP_RR	N/A	netperf	N/A	Latency, Throughput and Bandwidth	Marcio Silva
coremark6	1Xcoremark	single ("default")	N/A	coremark	Number of operations to be executed	Latency, Throughput	Marcio Silva
filebench8	1Xfilebench	fileserver oltp_noism varmail videoserver webproxy	Generated for each new load level	filebench	N/A	Latency, Throughput	Marcio Silva
ddgen8	1Xddgen	single ("default")	Generated for each new load level	dd	Number of blocks written	Bandwidth	Marcio Silva
nullworkload11	1Xtinyvm	single ("default")	N/A	N/A	N/A	N/A	Marcio Silva

Comments:

1. Requires preparation of the environment (Hosts with KVM) before it can be used. VM images will have to be manually copied to each Host before starting.
2. None.
3. OpenStack Folsom only.
4. The deployed daemon is part of CBTOOL's code, and works as an "endpoint" for the requests sent by CBTOOL. The deployment means that during cloud attachment, CBTOOL will ssh into the VM "webservice" (part of a normal SCP installation) and copy (and execute) the Ruby daemon originally located on (~/cbtool/scripts/common/scp2_python_proxy.rb).
5. Simulated cloud just creates concrete objects (e.g., Hosts and VMs) and abstract objects (e.g., Virtual Applications) on the Object Store only. Since the each operation takes only 1 second, it is a good way to test your experiment plan before running it on an actual cloud. In addition to that, this "cloud" is heavily used for debugging/development.