Optimization

General

In daily operations, Bacularis utilizes both Bacula resources (Catalog database, Bconsole, configuration files) and its own resources in various ways. Depending on the configuration, each of these areas can impact the performance of the web interface. This chapter provides techniques for improving Bacularis performance by making small adjustments to both the Bacula and Bacularis environments.

DNS

In many cases, if you use hostnames in address directives, poor performance may be caused by a slow-responding DNS server. For example, if opening Bconsole takes 1 second, and Bacularis uses Bconsole four times when loading a page, that results in a 4-second delay just for establishing the Bconsole connections.

There are two address fields that are particularly important for Bacularis performance:

• The Address directive in bconsole.conf, which defines the Director’s address.

• The address used by the Bacularis API to access the Bacula Catalog.

To improve performance, make sure to use IP addresses instead of hostnames in both locations whenever possible.

Example for bconsole.conf:

Director {
  Name = "bacula-dir"
  DirPort = 9101
  Address = "127.0.0.1"
  Password = "OYAQ8DZyPEoyvNrAKwo9E+0/PrsU1MDGJQoVMio0UWk="
}

The Bconsole response time can be measured for example by this command:

echo 'quit' | time -p bconsole

Database

A properly configured and optimized database is one of the most critical factors for improving Bacularis performance. After installation, database servers typically use default configurations, which may not be optimized for your specific environment. Fortunately, there are tuning tools available that can help identify and apply more efficient settings.

PostgreSQL

One useful tool for tuning PostgreSQL is PGTune. This is an online tool where you input your system’s specifications, and it generates optimized PostgreSQL configuration options for the postgresql.conf file.

You can access this tool here: PGTune.

Another helpful tool is PostgreSQL Configurator, which works similarly. It takes system parameters as input and provides recommended configuration directives.

Available here: PostgreSQL Configurator.

MySQL/MariaDB

For MySQL or MariaDB, a recommended tuning tool is MySQLTuner. Written in Perl, this script analyzes your current database setup and suggests configuration changes to optimize performance. It works equally well with both MySQL and MariaDB.

You can find this tool here: MySQLTuner.

Video guide

Web server

Bacularis can transfer large data structures between the web interface and the web browser. Typically, this is not noticeable in local networks where both the Bacularis web interface and the browser are on the same network. However, the web interface may slow down if the communication takes place over the Internet or a slow network. To mitigate this, it’s recommended to enable HTTP compression on the web server.

Apache

For the Apache web server, the first step is to ensure that the compression module is enabled. In this case, we use the deflate compression module. To enable it, add the following line to the Apache configuration:

LoadModule deflate_module modules/mod_deflate.so

Once the module is enabled, you can configure compression by adding the following lines to the <Directory> section of the Bacularis virtual host configuration file (e.g., bacularis.conf):

<Directory /usr/share/bacularis/htdocs>
      AddOutputFilterByType DEFLATE text/html
      AddOutputFilterByType DEFLATE text/css
      AddOutputFilterByType DEFLATE application/javascript
      AddOutputFilterByType DEFLATE application/json
      ...
      ... other options
</Directory>

After making these changes, reload the Apache configuration.

Nginx

In Nginx, you can enable HTTP compression by adding the following lines to the existing server block in the Bacularis Nginx configuration:

server {
  gzip on;
  gzip_types application/javascript application/json text/css text/html;
  ...
  ... other options
}

After editing the configuration, reload Nginx to apply the changes.

Lighttpd

For Lighttpd, make sure the mod_deflate module is installed (available since Lighttpd version 1.4.42).

Here is a sample configuration to enable HTTP compression in the Bacularis Lighttpd configuration:

server.modules = (
     "mod_deflate",
     ...
     ... other modules
)
deflate.mimetypes = ("text/html", "text/css", "application/javascript", "application/json")
deflate.allowed-encodings = ("br", "gzip", "deflate")
...
... other options

After saving the changes, reload the Lighttpd configuration.

Video guide

Bacularis

Job options

If your Bacula environment contains a large number of jobs (thousands or even hundreds of thousands), it’s important to configure two key options to limit the number of jobs displayed in the web interface. These options can be found in the Bacularis web interface under the Application settings page (accessible from the top-left gear icon), in the Display options tab:

• Max. number of jobs visible in tables - This defines how many of the most recent jobs will be displayed in the interface. In most cases, it’s not necessary to load all historical jobs at once. By default, this is set to 15,000. If the interface becomes sluggish, try reducing this number. Conversely, you can increase it if you need access to more jobs.

• Job age on the dashboard job graphs - This controls how many days of job data are used in the dashboard graphs. A large time range may slow down the dashboard. In versions up to 2.7.0, the default was 0 (which meant all jobs were included). Starting from version 2.7.0, if not explicitly set, the default is 14 days. It’s recommended to set this to a meaningful value, such as 7 days, instead of leaving it at 0.

Both of these options are marked with red arrows in the screenshot below:

Debug mode

If you previously enabled Debug mode for either Bacularis Web or the Bacularis API (or both), make sure to disable it once you’re done debugging. Keeping debug mode enabled permanently is not recommended, as it can negatively affect performance. While active, all command outputs are continuously written to log files, which increases disk usage and slows down the system.