View source | View content page | Page history | Printable version   

Projects:Stack Configuration for Performance



The aim of this project is to create documentation explaining how the stack (Tomcat, DB, etc...) should be configured in order to make Openbravo performant.

It should give a guideline which should be usable as a starting point for typical installations.


The following gives an overview about the rest of this document. It can serve a a quick checklist which can be used to sign-off on when configuring or reviewing installations.

The sections below detail on why and how to implement those recommendations.

  1. Use latest Confirmed Stable (CS) Release from Openbravo: 3.0PR23Q3.1
  2. Use latest available Browser version of a supported browser.
  3. Use HTTP compression (automatic if using new Openbravo Appliance)
  4. On PostgreSQL use major version 9.1 and not 8.3 or 8.4
  5. Tomcat memory configuration
  6. PostgreSQL configuration
  7. Useful Openbravo features / Addon modules
  8. Monitoring

Openbravo (Version)

To ensure good performance it is important to run a recent version of Openbravo. Ideally the latest Confirmed Stable (CS) release.

The current Confirmed Stable release is: 3.0PR23Q3.1

In addition of receiving bug-fixes nearly every Openbravo update is improving general performance by either:

This blog post on improving openbravo performance gives a good overview about some bigger performance related projects which have been delivered recently.

To get an overview about the numerous smaller performance fixes lookup the list of issues tagged with Performance in the Openbravo issue tracker. To know exactly in which release a fix is included please refer to the Release Notes and the Release Changelog.

Browser (Version)

As most current web-based software with Openbravo the Browser is doing the heavy-lifting regarding the User Interface.

It is important to run a recent version of your favorite Browser as those regularly have improved performance.

Also for security reasons you should always run the latest version of your browser.

Bulbgraph.png   Internet Explorer 10 and 11 did render a sub-optimal user experience for Openbravo which has been adressed with the recent PR14Q2 release.


Bulbgraph.png   By using the Openbravo Appliance based on Ubuntu you get this configuration by default and do not need to change anything.

To optimize network transport only one configuration change is important which is to HTTP compression.

This compresses data send from the server to the browser transparently and thus can reduce data transferred and access time significantly.

To configure this manually please refer to the Compression section of the Custom Installation manual.

PostgreSQL version

Bulbgraph.png   By using the Openbravo Appliance based on Ubuntu you get this configuration by default and do not need to change anything.

On PostgreSQL based installation we strongly recommend to run version 9.1.

If your installation is still running with 8.3 or 8.4 we strongly recommend updating it.

That applies mostly to users of one of the following deployment options:

The recommended deployment is to use the Openbravo Appliance. Migrating to it is explained here.

Application Server: Tomcat

For the Tomcat part only one group of parameters is interesting to reconfigure which are 2 Java memory related parameters.

  1. Java Permanent Generation (-XX:MaxPermSize): You normally never need to raise this parameter above the default value of 256MB. This parameter does not depend on load or data size but solely on the number of loaded java classes so in practice it does not need to be touched unless running multiple Openbravo copies inside one tomcat instance.
  2. Java Heap (-Xmx parameter): This parameter is important to scale up with the system usage. However this is mostly about avoiding very bad system performance when using nearly all of the configured memory and not so much improving performance otherwise. It can be hard to estimate a good general value valid for all instances without measuring average heap memory used in an instance. So a few basic rules to help with selection
    1. Needs to be set high enough to avoid using >95% of the configured value. As that the system will essentially come to a complete halt
    2. It should cover average normal heap memory usage
      1. Current rough heap usage can be seen by running the following command and summing up numbers of Eden Space - used & PS Old Gen - used
      2. sudo jmap -heap `jps -l | grep 'Bootstrap' | cut -d' ' -f1`
    3. Plus some buffer to allow for big transactions complete which need more memory
    4. If a system does not use all it's heap memory then increasing the maximum does not increase system performance (but can give extra buffer to absorb big transaction or load spikes)
    5. The table below gives some values to start with for various available memory settings.

Database Server


There are many many parameters which can be tuned trying to improve performance. However there are few main ones which give already most of the benefit.

This guide focuses on those very few which concrete recommendations and points to further external documentation in case more tuning is needed. In most cases it should not be needed to further fine-tune the database system in a typical installation.

The following lists those few basic configuration parameters which are all found inside the main PostgreSQL configuration file. (in Openbravo Appliance based on Ubuntu: /etc/postgresql/9.1/main/postgresql.conf)

Again the table below gives some values to start with for various available memory settings. If a value is not listed for a specific configuration that means it can be left at its default setting.

  1. shared_buffers: Main parameter affecting memory usage of the database. Raising this to use more memory for caching of frequently used data. This can speed up operations significantly. Raising this also requires to raise some kernel limits which is explained in more detail here
  2. work_mem: This parameter affects memory usage of internal operations in queries (sort, unique and so on). The memory set here will be used several times per running query for every connection. This parameter can be very difficult to adjust safely so we recommend to keep it at a low setting < 4MB.
  3. effective_cache_size: This parameter does not specify memory usage directly but rather how much memory the operating system is expected to have available for disk caching. On a linux based system this corresponds to the average number of 'cached Mem' on a loaded system.
  4. checkpoint_segments: This value affects write performance of the database system. We recommend to raise to a value of 16 to get better performance.

Much more information about those parameters and more can be found in the Tuning your PostgreSQL Server and Resource Consumption documentation of the main PostgreSQL website.


For Oracle we recommend to configure it with a memory target which is the amount of total system memory it should use.

That way Oracle will automatically adjust other parameters as necessary.

Example Memory Settings

This table gives example settings for both Tomcat and PostgreSQL based on available system memory for one server running both Tomcat & PostgreSQL.

The column "Unallocated" is the amount of not directly allocated system memory.

Leaving this memory not allocated is intentional as it will be used by the Operating System for caching.

This is important as it will directly benefit database performance as it also advised to PostgreSQL by setting the effective_cache_size parameter.

Amazon instance type Available RAM Tomcat PermGen Tomcat Max Heap PostgreSQL shared_buffers Unallocated Extra config
m1.small or c1.medium 1.7G 256M 1G 128M 332M
m3.medium or c3.large 3.75G 256M 1.5G 0.5G 1.5G work_mem=4M


m3.large or c3.xlarge 7.5G 256M 2.5G 2.5G 2.25G work_mem=4M


m3.xlarge or c3.2xlarge 15G 256M 5G 5G 4.75G work_mem=4M


m3.2xlarge or c3.4xlarge 30G 256M 8G 12G 9.75 work_mem=4M


Bulbgraph.png   If any memory related settings is raised to high it is possible that the system will crash because of running out of available memory. Those settings need to be done carefully to avoid this.

Openbravo (Configuration/Tools)

This sections highlights some useful Openbravo features or Addon modules related to

Openbravo Core Features

Addon Modules


This section points to several tools which are very useful to monitor application and system performance.

Application Level Monitoring

Monitoring on this level can give good insight into application behavior for both analyzing errors as well as detecting performance problems.

From experience we can recommend the commercial software AppDynamics as it has proven very useful already in debugging performance related problems in several Openbravo installations.

System Level Monitoring

Additionally monitoring on system level is important to ensure that the server(s) which are running the application are running fine.

Some example for metrics to monitor here are:

The recommend tools on a linux based is Munin which is easy to install and flexible enough.

Database Level Monitoring (PostgreSQL)

When running a PostgreSQL based system the following two configuration options should be used to allow to gather important performance metrics

Retrieved from ""

This page has been accessed 13,095 times. This page was last modified on 27 May 2015, at 13:16. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.