Server Benchmarks
From AlfrescoWiki
Back to Server Configuration
Contents |
[edit] Introduction
This page documents the benchmark suite available since Alfresco 2.1 (from 2.1.2). The page to the old benchmarks can be found here.
There is a new remotely-driven benchmark client that can be run against any standard server installation. The aim is to provide a simple Java client that can call through to a standard remote Alfresco installation (cluster or single machine) and provide an indication of the performance of the configuration.
The Remote Benchmark Client communicates with Alfresco over RMI. The services exposed over RMI are not fit for production-level clients, although the general infrastructure can be used to expose any number of services for other client code to use.
All files can be downloaded directly from the Alfresco Nightly Distributions or from one of the Alfresco Enterprise V2.x (from 2.1.2) or V3.x releases. It is also available for Alfresco Community.
[edit] Activating the Server Remote APIs
Although the exposed services on the server are fully protected by the necessary authentication mechanisms, a sample file still needs to be enabled to expose them. The overhead of exporting these service to RMI is low but it is probable that product-ready configurations will not want to expose the APIs in case excessive loads are placed on the server by accident.
Download the Alfresco Sample Extensions (alfresco-community-sample-extensions-AAA) and extract the file bm-remote-loader-context.xml.sample to <extension>/bm-remote-loader-context.xml. This must be done for each server that will be used by the client. Note that the bm-remote-loader-context.xml.sample file is included by default in most Alfresco Enterprise bundles in the alfresco/extension folder, obviating the need to download the community sample extensions.
[edit] Getting the Client
The client is packaged in a self-contained jar file named alfresco-bm-AAA.jar.
If you wish to build the client from the source, use the following after a full build:
ant -f continuous.xml distribute-bm-remote
[edit] Client Configuration
The client is initialized using setting read from a Java properties file. The location of this file is provided in the start up command.
session.name=TEST session.sourceDir=c:/temp session.rmiUrls=rmi://localhost:50500/ session.storeIdentifiers=TEST-01, TEST-02, TEST-03, TEST-04, TEST-05 session.folderProfile=1, 10, 10, 10, 10, 10 test.load.upload.fast=2, 0, 10000, 6, false, 1 #test.load.totals.basic=1, 15000, 0, 1, true
The config is divided into two sections. The session section controls behaviour across all execution threads, while the test.load section controls specific thread behaviour.
[edit] Session Properties
- session.name: The name that will get put on the output files.
- session.sourceDir: The directory in which to find files for upload tests. All files with extensions will be used and subdirectories will be ignored.
- session.rmiUrls: The RMI addresses of all servers that are to be used. These must all be part of a cluster and tests will distribute the load randomly across them. Where more than one server is specified, a check is performed to ensure that the cluster replication is working properly.
- session.storeIdentfiers: Identifiers for all stores that can be used by the tests. The store to use is chosen randomly each time.
- session.folderProfile: Each store will have a working root node created, below which folders named folder-00001, folder-00001', etc will be created. Starting with the mandatory 1 representing the working root node at level 1, each number represents the number of subfolders. So, for example, 1, 10, 10 represents 111 folders going from level one to level three.
[edit] Test Properties
Each test property has four comma-separated values to control specific behaviour. So for example:
test.load.upload.fast=2, 0, 10000, 6
- 2: The number of threads like this to start.
- 0: The time to wait (milliseconds) between execution of each thread.
- 10000: The maximum number of iterations.
- 6: The folder depth to work at.
- false: If set to true, a message will be dumped to the verbose log file with each iteration. Switch this on for summary threads and off for the main loading threads.
- 1: The number of documents to upload in a single transaction. This defaults to 1, but can be any number above 0.
There are two types of test, currently:
- test.load.upload.<name>: Loads files into the system. A random source file is chosen and uploaded to a random server into a random store along a random folder path name. Initially, the load of creating the folders will impact performance, but this will become insignificant if the number of iterations exceeds the number of folders by a significant amount.
- test.load.totals.<name>: Fetches and reports the number of nodes in the repository and in each store. This is very useful for the command line s option. BUG NOTE: This thread will issue a select count(*) statement, which runs poorly at large volumes on some databases. If the s option at the console takes too long, then it is a symptom of this bug.
[edit] Running the Client
java -Xmx128M -jar alfresco-bm-AAA.jar --username=<username> --password=<password> --config=<path to config>
After startup there will be three files named after the session name, the start time and the nature of the output.
- LoaderSession-<session name>-<time>-error.tsv
- LoaderSession-<session name>-<time>-verbose.tsv
- LoaderSession-<session name>-<time>-summary.tsv
Changes and progress can be tracked using the Unix or Cygwin tail -f command.
Once started, you can generate an ad-hoc summary to the console by entering 's' and can quit by entering 'q'. After manually quitting, the client will wait for all threads to finish their current operations before exiting.
[edit] An Example
Load 10,000 documents into a folder structure 6 levels deep, partitioning the data across 10 stores. The machine is a 4 X Dual Core machine, so 16 client threads should be adequate.
- /data/loader.properties:
session.name=10K-INITIAL session.sourceDir=/data/source-files session.rmiUrls=rmi://localhost:50500/ session.storeIdentifiers=01, 02, 03, 04, 05, 06, 07, 08, 09, 10 session.folderProfile=1, 10, 10, 10, 10, 10 test.load.upload.fast=16, 0, 625, 6, false #test.load.totals.basic=1, 60000, 0, 0, true
java -Xmx128M -jar alfresco-bm-2.2dev.jar --username=admin --password=admin --config=/data/loader.properties
[edit] The Results
Summary results are reported for each thread. For example:
NAME COUNT TOTAL TIME AVERAGE TIME PER SECOND DESCRIPTION
test.load.totals.basic 5 0.290 17.213 0.058 Total=657, TEST...
test.load.upload.fast 88 71.174 1.236 0.809
test.load.upload.fast 83 70.974 1.169 0.855
There were 2 threads named test.load.upload.fast. They completed an iteration in 1.236s and 1.169s respectively. Inverting that, they took 0.809s and 0.8555s per operation. Between them, the two threads performed 1.664 operations per second.
