Overview
AceMQ does not operate Apigee — Google does. What we do is help teams debug and tune what they built on top of it: proxy logic, policy chains, shared flows, target server configuration, and the integration layer between Apigee and the backends it fronts. That is the layer platform support generally will not touch.
Challenge
Latency on several proxies had grown to the point of breaching internal SLAs, and platform support had correctly reported that the runtime was healthy. The proxies included JavaScript policies doing synchronous work, a ServiceCallout to an internal identity service with no timeout set, and message payload logging that captured full request and response bodies on high-volume traffic.
Environment
Apigee X on Google Cloud fronting containerized backend services, with proxies developed by several internal teams over time.
Approach
AceMQ used Apigee trace sessions to attribute time to individual policies within each proxy flow, then reviewed the proxy bundles as code. We treated the proxy bundle as an application under performance review rather than as configuration.
Solution
- Used trace sessions to attribute latency to individual policies within request and response flows
- Set explicit timeouts and fallbacks on ServiceCallout policies to external dependencies
- Replaced synchronous JavaScript policy work with native policies where equivalent behavior exists
- Reduced message logging scope so full payload capture stopped running on high-volume paths
- Reviewed target server and connection reuse settings against backend keepalive behavior
- Established a proxy performance review step before new proxies are promoted
Outcome
Proxy-added latency returned within the internal SLA, and the team gained a repeatable method for attributing latency to policies rather than escalating whole-proxy slowness to platform support.
Technologies
Apigee
Kubernetes
Docker
Kong
Redis
PostgreSQL
NGINX
