# DevOps

## Cache clearing

### Clearing file cache using the Symfony cache:clear command

Symfony provides a command for clearing cache. It deletes all file-based caches, which mainly consist of a Twig template, a [service container](https://doc.ibexa.co/en/latest/api/php_api/php_api/#service-container), and the Symfony route cache, but also everything else stored in the cache folder. Out of the box on a single-server setup this includes Content cache.

For further information on the command's use, see its help text:

```
php bin/console --env=prod cache:clear -h
```

Note

If you don't specify an environment, by default `cache:clear` clears the cache for the `dev` environment. If you want to clear it for `prod` you need to use the `--env=prod` option.

Clustering

In [clustering](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/clustering/clustering/index.md) setup (with several web servers), the command to clear file cache needs to be executed on every web server.

### Clearing content cache on a cluster setup

For a [cluster](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/clustering/clustering/index.md) setup, the content cache ([HTTP cache](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/cache/http_cache/http_cache/index.md) and [Persistence cache](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/cache/persistence_cache/index.md)) must be set up to be shared among the servers. While all relevant cache is cleared for you on repository changes when using the APIs, there might be times where you need to clear cache manually:

- Varnish: [Cache purge](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/cache/http_cache/reverse_proxy/#using-varnish-or-fastly)
- Persistence Cache: [Using Cache service](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/cache/persistence_cache/#using-cache-service)

## Web Debug Toolbar

As of Ibexa DXP v4.5, the [Symfony Web Debug Toolbar](https://symfony.com/doc/7.4/profiler.html) is no longer installed by default. To install it, run the following command:

```
composer require symfony/debug-pack
```

After you have installed Symfony Web Debug Toolbar, it's available when running Ibexa DXP in the `dev` environment. It's extended with some Ibexa DXP-specific information:

#### SPI (persistence)

This section provides the number of non-cached SPI calls and handlers. You can see details of these calls in the [Symfony Profiler](https://symfony.com/doc/7.4/profiler.html) page.

#### SiteAccess

Here you can see the name of the current SiteAccess and how it was matched. For reference see the [list of possible SiteAccess matchers](https://doc.ibexa.co/en/latest/multisite/siteaccess/siteaccess_matching/#available-siteaccess-matchers).

## Logging and debug configuration

Logging in Ibexa DXP consists of two parts. One are several debug systems that integrate with Symfony developer toolbar to give you detailed information about what is going on. The other is the standard [PSR-3](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md) logger, as provided by Symfony using [Monolog](https://github.com/Seldaek/monolog).

### Debugging in dev environment

When using the Symfony `dev` [environment](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/environments/index.md), the system tracks additional metrics for you to be able to debug issues. They include Symfony cache use, and a [persistence cache](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/cache/persistence_cache/#persistence-cache-configuration) use.

#### Reducing memory use

Tip

For long-running scripts, see [Long-running console commands](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/performance/#long-running-console-commands).

If you're running out of memory and don't need to keep track of cache hits and misses, you can disable persistence cache logging, represented by the setting `parameters.ibexa.spi.persistence.cache.persistenceLogger.enableCallLogging`. In `config_dev.yaml`:

```
parameters:
    ibexa.spi.persistence.cache.persistenceLogger.enableCallLogging: false
```

### Error logging and rotation

Ibexa DXP uses the [Monolog](https://github.com/Seldaek/monolog) component to log errors, and it has a `RotatingFileHandler` that allows for file rotation.

According to [their documentation](https://seldaek.github.io/monolog/doc/02-handlers-formatters-processors.html#log-to-files-and-syslog), it "logs records to a file and creates one logfile per day. It also deletes files older than `$maxFiles`".

Monolog's handler can be configured in `config/packages/<environment>/monolog.yaml`:

```
monolog:
    handlers:
        main:
            type: rotating_file
            max_files: 10
            path: '%kernel.logs_dir%/%kernel.environment%.log'
            level: debug
```

### Using `logrotate`

Monolog themselves recommend using [`logrotate`](https://manpages.debian.org/jessie/logrotate/logrotate.8.en.html) instead of doing the rotation in the handler, because it gives better performance.