Galco

Platform: Magento 2
Engagement: Performance Research & Optimization
Galco 1
Galco 2
Galco 3

Overview

Galco has been an industrial automation expert since 1975, distributing over 1 million PLCs, drives, HMIs, motors, and electronic components with same-day shipping and certified repair services. Their Magento 2 store runs a catalog of 1.4+ million products behind Varnish, Redis, and Cloudflare. We were engaged to perform deep performance research: find out where server resources were actually going, why pages were escaping the Full Page Cache, and which backend operations were slowing down real customers.

Challenge

  • •
    Cache Constantly Bypassed: Product pages were loading without Full Page Cache thousands of times a day — single products were bypassing the cache 1,000+ times daily, and a bug in a third-party search module meant no first-time visitor ever received a cached page.
  • •
    Marketing Traffic Hitting the Backend: Ad-click URL parameters (gclid, utm and friends) made Varnish treat every visit as unique — around 40,000 requests per month executed full Magento instead of being served from cache.
  • •
    Hidden API Load: One internal API endpoint was quietly generating 643,000 requests in a single day (~15 per second), and a catalog REST API call averaged over 8 seconds due to a count query walking all 1.4M products.
  • •
    Slow Customer Operations: Logging in took 3.2 seconds on average — and 1 in 100 customers waited 22+ seconds, because shipping rates were being estimated during login. Account creation hit 18 seconds at the 99th percentile.
  • •
    Wasted Server Time: 404 pages consumed 17.5% of total transaction time thanks to bot traffic and a brand-navigation module checking its routes on every request; ESI blocks fully bootstrapped Magento and topped the throughput charts.

Result

Full Page Cache & Varnish

  • ✓Installed Freento Full Page Cache Analyzer (extended with Varnish purge logging) to trace the exact source of every cache flush.
  • ✓Extended the Varnish VCL to strip marketing URL parameters — ~40,000 backend-hitting requests per month now served from cache.
  • ✓Root-caused the search module bug that prevented first visits from ever being cached, and delivered both an upgrade path and a targeted patch.
  • ✓Built and deployed a custom Full Page Cache warmer with CSV reporting on per-URL cache status.

API & Database

  • ✓Reworked the product listing count query on the 1.4M-product catalog: from 2 minutes 10 seconds down to 1.44 seconds.
  • ✓Fixed the login slowdown by removing shipping-rate estimation from the sign-in flow.
  • ✓Cut 404 page execution time by ~37% and delivered a plan to remove per-request routing overhead from a third-party brand module.
  • ✓Eliminated Redis lock contention and identified abnormal Redis connection delays for the hosting team.

Monitoring & Observability

  • ✓Performed a full New Relic-driven audit: transaction ranking, per-page-type cache analysis, error and log review.
  • ✓Enabled New Relic Browser monitoring (Core Web Vitals) and configured alerts for product page cache-miss spikes.
  • ✓Prototyped custom New Relic events on every cache flush, so cache-destroying actions are visible and traceable.

Impact

"On a 1.4-million-product catalog, the wins are measured in orders of magnitude: a 2-minute query now runs in 1.44 seconds, tens of thousands of monthly requests moved from the backend to the cache, and every cache flush is now visible and accountable."