# OroCommerce best practices

OroCommerce is a Symfony-based B2B commerce platform that depends heavily on caching, a message queue, and search indexing to perform well. This page covers the practices that keep an OroCommerce storefront fast and stable on TurboStack. OroCommerce is configuration-only: you bring your own code with [Git deployment](../../platform/hosts/applications/git-deployment.md), and TurboStack provisions the runtime and services around it.

## What TurboStack configures for you

When you set a vhost to `app_type: orocommerce`, the platform provisions the OroCommerce runtime profile:

- An **Nginx vhost** tuned for OroCommerce, with the document root at `public_html` under your system user's home (`/var/www/<username>/[<app_name>/]public_html`).
- A **PHP-FPM backend** wired to Nginx, with a long `fastcgi_read_timeout` (1200s) so long-running install and admin requests do not time out, plus `fastcgi_intercept_errors` for clean error handling.
- **Static asset caching** at the web server: images, CSS, JS, PDF and similar files are served with a 1-hour browser cache and access logging disabled.
- The **MySQL/Percona** database service (PostgreSQL is also supported).
- Optional **Redis**, **RabbitMQ** (the message queue Oro relies on), and **Varnish**, enabled per host.

> [!NOTE]
> TurboStack provisions the infrastructure; OroCommerce's own application configuration (cache adapters, queue, search) lives in your code and `.env`/`config` and is deployed with your repository.

## Recommended optimizations

Combine OroCommerce's own recommendations with the TurboStack services you enable on the [Services](../../platform/hosts/services.md) tab:

- **Run the application in `prod` mode** and compile assets/DI container during deploy; never serve `index_dev.php` in production.
- **Enable OPcache** for PHP and keep it warm; it is the single biggest PHP performance win for Symfony.
- **Use Redis** for the Symfony cache, doctrine result cache, and sessions to offload the database.
- **Run RabbitMQ message-queue consumers** as persistent workers - Oro offloads emails, search indexing, price recalculation and imports to the queue. Without running consumers these jobs stall. Run each consumer as a [user system service](../../technologies/system-services/manage-user-services.md) so it restarts on failure. Add more consumers in parallel to clear a backlog, but keep the total within the host's processor budget (see [Scale throughput with more instances](../../technologies/system-services/manage-user-services.md#scale-throughput-with-more-instances)).
- **Keep the search index healthy**: run application search reindexing after catalog changes and on a schedule.
- **Put Varnish in front of Nginx** for full-page caching of anonymous catalog traffic on high-volume storefronts.
- **Optimize images and assets**: compress product images and enable an HTTP cache/Content Delivery Network (CDN) in front of static content.
- **Schedule Oro's cron** (`oro:cron`) so recurring maintenance, cleanup and queued tasks run reliably.

> [!TIP]
> Message-queue consumers and the Oro cron are the two things most often forgotten. If emails, search updates or imports "do nothing," check these first.

## Sizing and scaling

TurboStack auto-tunes service defaults from the host's resources. Override sizing variables only when you have measured evidence of a bottleneck:

| Variable | Tune when |
| --- | --- |
| `mysql_innodb_size` | The working set exceeds the buffer pool. |
| `redis_memory` | Redis is evicting keys under load. |
| `varnish_cache_size` | The full-page cache hit ratio is low. |

Scale message-queue consumers and PHP-FPM workers to match traffic before scaling the database. See [Performance tuning](../../concepts/performance-tuning.md).

## Stability

- Keep **[Backups](../../platform/hosts/backups.md)** enabled and verify restores periodically - Oro holds catalog, order and customer data.
- Watch the host **[Health](../../platform/hosts/health.md)** tab for CPU, memory, queue depth and service status.
- Keep OroCommerce, PHP and the database versions current within supported ranges.
- Test upgrades, schema migrations and config changes on a **staging clone** before publishing to production.

> [!WARNING]
> Database schema migrations and reindexing are heavy operations. Run them in a maintenance window and ensure consumers are running so queued post-migration jobs complete.

## Related

- [Deploy OroCommerce](deploy.md)
- [Troubleshooting OroCommerce](troubleshooting.md)
- [How to manage user system services](../../technologies/system-services/manage-user-services.md)
- [Services](../../platform/hosts/services.md)
- [Performance tuning](../../concepts/performance-tuning.md)