Difference between revisions of "Benchmark LogicalDOC"

From LogicalDOC Community Wiki
Jump to navigationJump to search
m (Getting the Client)
 
(11 intermediate revisions by the same user not shown)
Line 15: Line 15:
  
 
== Getting the Client ==
 
== Getting the Client ==
The client is packaged in a .zip archive named '''logicaldoc-XXX-benchmark.zip'''.
+
The client is packaged in a .zip archive named '''logicaldoc-benchmark-xxx.zip'''.
 +
 
 +
== Client Configuration ==
 +
The client is initialized using setting read from a Java properties file. The location of this file is '''conf/context.properties'''.
 +
<pre>
 +
session.url=http://localhost:8080
 +
session.username=admin
 +
session.password=admin
 +
session.language=en
 +
loaders=Upload
 +
webservice.gzip=-1
 +
</pre>
 +
 
 +
The config is divided into several sections. The '''session.xx''' section controls behaviour across all execution threads, while the '''loader.xx''' sections control specific thread behaviour.
 +
 
 +
= Session Properties =
 +
* session.url: The URLs of all servers that are to be used. These must all be part of a cluster and loaders will
 +
distribute the load randomly across them.
 +
* session.username: The username to use for every loader
 +
* session.password: The password to use for every loader
 +
* session.language: language to be used in load operations (see Java 6 Locale, en=English)
 +
* loaders: List of the loaders to start (Search, Upload, ListFolders)
 +
* webservice.gzip: -1=no compression 0=all packets are comressed N=only packets > N bytes will be compressed
 +
 
 +
== Loader Properties ==
 +
Each loader property allows you to configure a specific behaviour of the loader itslelf
 +
 
 +
* Upload.threads: Number of concurrent threads
 +
* Upload.iterations: Number of iterations requested for each thread
 +
* Upload.rootFolder: Folder from which to generate the tree structure (4 is the Default Workspace)
 +
* Upload.sourcedir: Source folder of documents to be used for the upload
 +
* Upload.folderprofile: Profile for folder creation in terms of number of nodes in each level
 +
* Upload.depth: Level in which documents will be created in
 +
* Upload.loadinmemory: Load all the documents in memory to avoid IO on the disk
 +
* Upload.tags: Number of tags to be loaded
 +
* Upload.tagsize: Minimum size for a tag word
 +
 
 +
Actually there are different loaders: Upload, Update, Search, ListFolders
 +
 
 +
== Running the Client ==
 +
<pre>
 +
  # ./load.sh
 +
</pre>
 +
 
 +
After startup there will be three files named after the session name, the start time and the nature of the output.
 +
LoadSession-<time>.tsv
 +
 
 +
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.

Latest revision as of 08:32, 29 October 2012

Introduction

This page documents the benchmark suite available since LogicalDOC 6.5. 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 LogicalDOC installation (cluster or single machine) and provide an indication of the performance of the configuration. The Remote Benchmark Client communicates with LogicalDOC over SOAP. The services exposed over SOAP are also fit for production-level clients, and 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 LogicalDOC Distributions (http://sourceforge.net/projects/logicaldoc/files/distribution).

Activating the Server WebServices APIs

Although the exposed services on the server are fully protected by the necessary authentication mechanisms, a sample flag still needs to be enabled to expose them. In the Administration, go to Settings->Client and External Apps->WebServices and click on Enabled and press Save.

Getting the Client

The client is packaged in a .zip archive named logicaldoc-benchmark-xxx.zip.

Client Configuration

The client is initialized using setting read from a Java properties file. The location of this file is conf/context.properties.

session.url=http://localhost:8080
session.username=admin
session.password=admin
session.language=en
loaders=Upload
webservice.gzip=-1

The config is divided into several sections. The session.xx section controls behaviour across all execution threads, while the loader.xx sections control specific thread behaviour.

Session Properties

  • session.url: The URLs of all servers that are to be used. These must all be part of a cluster and loaders will

distribute the load randomly across them.

  • session.username: The username to use for every loader
  • session.password: The password to use for every loader
  • session.language: language to be used in load operations (see Java 6 Locale, en=English)
  • loaders: List of the loaders to start (Search, Upload, ListFolders)
  • webservice.gzip: -1=no compression 0=all packets are comressed N=only packets > N bytes will be compressed

Loader Properties

Each loader property allows you to configure a specific behaviour of the loader itslelf

  • Upload.threads: Number of concurrent threads
  • Upload.iterations: Number of iterations requested for each thread
  • Upload.rootFolder: Folder from which to generate the tree structure (4 is the Default Workspace)
  • Upload.sourcedir: Source folder of documents to be used for the upload
  • Upload.folderprofile: Profile for folder creation in terms of number of nodes in each level
  • Upload.depth: Level in which documents will be created in
  • Upload.loadinmemory: Load all the documents in memory to avoid IO on the disk
  • Upload.tags: Number of tags to be loaded
  • Upload.tagsize: Minimum size for a tag word

Actually there are different loaders: Upload, Update, Search, ListFolders

Running the Client

  # ./load.sh

After startup there will be three files named after the session name, the start time and the nature of the output. LoadSession-

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.