Debugging your proxies and policies, not Google's platform

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

Technologies