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 database service (PostgreSQL is also supported).
  • Optional Redis, RabbitMQ (the message queue Oro relies on), and Varnish, enabled per host.

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. The broker credentials and the connection string are described in Connect your application. 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.

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.