Ruby store performance tuning

Performance tuning in the Ruby store is important for delivering the best browsing experience. If your storefront is slow, you can improve its performance by checking and optimizing the following points.

Grafana dashboard

From version 9.1.15 onwards HCL Commerce provides support for the Grafana dashboard for the Ruby store and helps troubleshoot performance problems with Next.js servers. The dashboard is designed to monitor different server metrics. For more information, see https://github.com/HCL-TECH-SOFTWARE/hcl-commerce-performance/tree/main/Grafana/dashboards/chart/dashboards/prometheus-operator.

Worker threads

From version 9.1.14 onwards HCL Commerce uses cluster API in the Ruby store implementation to help multiple worker threads improve performance. This is achieved using the NODE_INSTANCE_NUMBER variable. The NODE_INSTANCE_NUMBER environment variable sets the number of Node.js instances for deployment in the Next.js store container. The NODE_INSTANCE_NUMBER is read from the environment variable during deployment. If not specified, it derives from the CPU units in the helm chart for the Next.js container.

Note: To address a high load and CPU situation, add more CPUs and worker threads to manage the increased volume.

CPU Throttling

If resources are not configured correctly, CPU throttling may increase response time. Check the Grafana dashboard for CPU throttling in HCL Commerce version 9.1.15 and above. If CPU throttling is detected in the Grafana dashboard, recommend horizontal pod autoscaling or adjust the cluster's node resources.

Memory

For memory-related tuning or issues like memory settings and handling Out of Memory (OOM) situations, visit the Node.js article at https://nodejs.org.

To support stable performance and high availability during peak load, apply the following HCL Commerce-aligned performance settings:

Runtime and container memory strategy


Strategy	Description
V8 heap budgeting	Set `NODE_OPTIONS="--max-old-space-size=<MB>"` in the Next.js storefront Docker or Kubernetes container environment variables.
Heap-size calculation	Set `--max-old-space-size` to approximately 75–80 percentage of the kubernetes container memory limit. For example, for a container with a `4Gi` memory limit, configure `--max-old-space-size=3200`. Reserve the remaining memory for Node.js native memory, buffers, and other container processes. This reduces the risk of the container reaching its Kubernetes memory limit before Node.js can reclaim memory.
Standalone build deployment	Configure the storefront to use `output: 'standalone'` in `next.config.js`. This creates a smaller deployment footprint by excluding unnecessary build artifacts and can reduce container startup time.

Two-tier search and storefront caching optimization

The Ruby storefront uses two caching layers: Browser cache and Next.js server-side cache.


Optimization	Details
Server-side cache synchronization (1-minute TTL)	Configure the Next.js server-side cache with a 1-minute TTL for catalog and search queries to limit stale responses. Ensure custom backend fetchers do not use an unconstrained `cache: 'force-cache'` configuration for dynamic transaction APIs such as Cart, User, and Order.
Browser cache invalidation	After catalog updates or delta-index jobs in HCL Commerce Search (Elasticsearch or Solr through the Orchestration Service), wait at least 1 minute before verifying storefront changes. This allows the configured server-side cache TTL to expire before validation.
Avoid `getServerSideProps` bottlenecks	Minimize blocking REST API calls in server-rendering hooks such as `getServerSideProps`. Reducing long-running server-side requests helps lower rendering latency, request concurrency, and Node.js memory pressure.