OroCommerce best practices

Performance and stability best practices for OroCommerce on TurboStack - Redis cache, RabbitMQ consumers, OPcache, Varnish, search reindexing and sizing.

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, 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 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 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).
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.

Stability

Keep Backups enabled and verify restores periodically - Oro holds catalog, order and customer data.
Watch the host Health 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.