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, 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_htmlunder 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, plusfastcgi_intercept_errorsfor 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.
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
prodmode and compile assets/DI container during deploy; never serveindex_dev.phpin 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.
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:
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.
Related
- Deploy OroCommerce
- Troubleshooting OroCommerce
- How to manage user system services
- Services
- Performance tuning