Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Load Testing Sugar Cheat Sheet
# Download from here:
# Copy Tidbit to your Sugar Root and unpack
cp /var/www/html
# Run Tidbit
cd Tidbit
php -f install_cli.php -- -c
# Disable AJAXUI
cd /var/www/html
echo '$sugar_config[\'disableAjaxUI\']=true;' >> config_override.php
# Make sure you can login as one of the users. The password is the same as the user name
# e.g. user8 / user8
# Disable PHP Safe Mode
# safe_mode = off;
# Run it
sh /var/www/html/jmeter/ 6.5.16 Ent 10000 100 localhost
jmeter load tester
This package contains the jmeter based load testing tool for SugarCRM.
It contains a full working copy of Apache's jmeter tool, which is subject
to the Apache License, Version 2.0.
* java JRE 1.5+ (1.6 is widely in within Sugar's own testing)
* a *nix platform
* PHP 5.2.x
* cli sapi (--enable-cli)
* ext/pcntl (--enable-pcntl)
* safe_mode = off
Installing and Running
There is no installation, once PHP and java are setup, just unpack the
jmeter tarball, change directories to jmeter/PerformanceRunner and execute
the runner:
* ./run_jmeter_generate_results_studio.php -h
If successful, you will receive a message along the lines of:
Usage: run_jmeter_generate_results_studio.php ...
The various options give you a lot of control in configuring the test that
is run along with the parameters passed to the JVM when executing jmeter.
Of those parameters, here are a few of the most commonly used
-l --logfile=<value> File to log to:ta
-n --concurrent=<value> Number of concurrent users (100)
--time=<value> Amount of time in minutes to run the test.
--test-server=<value> Server to connect to for testing
--test-server-path=<value> Path, relative to "test-server", of the code
to test (sugarcrm)
-s --script=<value> Script to run (SimpleLoadReadIntensive.jmx)
Doing Round-Robin Tests
You can mimic a load balancer by using one of the round robin tests by specifying
the script of the following when running:
-s SimpleLoadReadIntensiveRoundRobin.jmx
-s SimpleLoadReadIntensiveRoundRobinServerAndPath.jmx
When running in a round robin, there are two additional parameters that are useful:
--max-servers=<value> Max number of servers to utilize when in
round-robin (3)
--max-paths=<value> Max number of paths to utilize when doing a
round-robin on paths (3)
Using these, you can specify that you would like to do a round robin on <value>
servers or paths. The `--max-paths` parameter is only used with the
*ServerAndPath.jmx file. The round robin expects the `--test-server` and if
using the *ServerAndPath.jmx script the `--test-server-path` to be specified
without the the #.
1. Install SugarCRM
- Install a Pro/Ent/Corp/Ult edition of SugarCRM as normal.
- Be sure that any user that is going to be used as a test user has
run through the first-time login functions, the script does not have
code in it to run through the initial login wizard.
- If you are going to be using tidbit do not have the installer
generate demo data for your installation.
- DISABLE Ajax UI. Jmeter's parsing of json is pretty much non-existant,
so to avoid having some crazy escape sequences to pull things out of
raw json text the jMeter tests were not built to handle the AJAX UI.
2. Load test data into SugarCRM
- If you are doing a small/local test or you are just trying this for
your first time you can just use the demo data populated in the
install of SugarCRM
- For testing a clone of an instance the only thing you will need to
do is make sure the passwords for all of the users you will be using
during the test match the username. So just like the demo users, have
the username be the same as the password.
- For using Tidbit follow the Tidbit instructions making sure to
generate enough users for the load you want to generate on JMeter, and
then after you are done be sure to run the script in
"extras/tidbit_fixup.sql". This SQL script changes all team permissions
to global because the current Tidbit system does not generate data
with proper permissions attached and that throws the system off when
it is trying to test relationship building.
3. Run the data builder
- The build_data.php loads data from your installed sugar instance and
builds the csv files for JMeter to use for searching and other things
during the performance test.
- To run the databuilder just run
php build_data.php -s /path/to/sugar
- By default the databuilder will generate data for 10 users and a
single JMeter server. If you wish to increase these numbers please use
the "-u" and "-n" options respectively.
- The data builder will leave the generated data for the primary server
in the data_gen/1/ directory, copy this directory over to the data/
directory. If you are running on multiple JMeter servers just copy the
corresponding data_gen/<n>/ directory to each of the JMeter servers.
- When this process is complete, make sure there is a file named
4. Run JMeter warmup script
- This script takes the same parameters as the real JMeter script,
it's recommended that leave the loops set to "2" and set the
output_suffix to "warmup", other than that you can change it as you
please, you should however use the same num_threads as the main test
so that every user has a chance to pre-run through every page.
5. Run JMeter
- The JMeter test has various parameters that you can pass to it, some
of them are vitally important in order to get JMeter to run tests
against the desired instance. Here is a list of the parameters it can accept.
- In order to pass parameters to JMeter you run JMeter with the
following command line: "java -jar ApacheJMeter.jar -n -t
/path/to/sugarcrm.jmx -Jsugar_host=lt-web1 -Joutput_suffix=localtest"
- If you wish to run JMeter with the GUI visible, don't pass the "-n"
command line option.
6. Load the results in to the result database
- Change to the "web" directory, the result database is built in the
current directory and the index.php file that processes the charts
looks for it in the current directory.
- Run the command "php readJmeterResults.php
--jmeterResults=../output.xml --branchName=coconut --buildNum=9999"
7. View the results
- Make sure your web server has access to the "web/" directory.
- Navigate to that directory there should be a graph of recent builds
and you should be able to select that build and compare it against
previous builds to see various performance figures for the run.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment