APM Monitor Interation

[noelsaw1]

Short answer: New Relic can partially do this, but it's the wrong tool for your specific problem. Blackfire or Tideways are purpose-built for exactly what you're trying to do.

Here's the breakdown:

---

New Relic — what it actually gives you

New Relic's PHP agent will give you:

• Transaction traces with SQL queries attributed to a specific request
• Slow query logs with parameterized SQL
• Distributed tracing across request chains

The gap for your use case: New Relic lets you see slow transactions and drill into transaction traces, identifying the slowest components, but it doesn't give you a PHP call-stack attribution from the SQL back to the PHP function that issued it. You'd see shop_coupon appearing in query traces, but you'd still have to manually correlate it to WC_SC_Coupon_Actions::get_coupon_actions(). It also won't run locally against Local WP — it needs a real server with the agent installed.

---

What actually solves your exact problem

1. Blackfire.io (best fit, quick win)

Blackfire provides context for slow SQL queries and HTTP requests, and can identify context on other functions such as template engines or event dispatchers. It instruments the real call path from SQL → PHP method, exactly the attribution gap you're hitting with Xdebug right now. It works via a browser extension or CLI trigger against Local WP. You'd get a call graph that shows get_posts() → caller → caller chain directly linked to the SQL query that fired.

Practical path: Install the Blackfire PHP extension in Local WP's PHP environment, use the Chrome extension to trigger a profile on the homepage-after-prep request, and the flamegraph will directly show you whether WC_SC_Coupon_Actions::get_coupon_actions or WC_SC_URL_Coupon::apply_coupon_from_session is the issuing call.

2. Tideways (better for ongoing production monitoring)

Tideways includes a Slow SQL Query Log that functions like a classic database slow query log, but which also provides application context, helping you quickly identify and fix faulty SQL queries. Their WordPress-specific timeline traces show first-class support for database calls mixed with PHP profiling insights, showing calls on the same timeline. This is better than New Relic for PHP-specific attribution, but it's SaaS-only and requires a running server — not ideal for Local WP unless you expose it.

3. Query Monitor + SAVEQUERIES (free, already installed)

You already have QM installed. The missing piece isn't a new tool — it's correlating the right request to the right QM output. The coupon URL application request (/?coupon-code=binoid15&sc-page=cart) and the homepage request are two separate PHP processes. Your current Playwright flow visits both, but QM only shows queries for the page it's embedded in. You need to:

1. Add define('SAVEQUERIES', true) to wp-config.php
2. Capture $GLOBALS['wpdb']->queries at shutdown via a one-off MU plugin that writes it to a log file with the full backtrace column QM already populates

This gives you the PHP backtrace from SQL → calling function without any new tools.

---

Recommended order

1. Immediate: Drop a one-line MU plugin using SAVEQUERIES + shutdown hook to dump $wpdb->queries (with backtraces) to /tmp/wpdebug-queries.log for each request. Run the Playwright prep flow. Read the log. This will resolve the "which request owns the query" ambiguity within 30 minutes.

2. Short-term: Install Blackfire in Local WP's PHP environment. It plugs the Xdebug gap (profile mode missing + no call-path attribution) and gives you the flamegraph you need to confirm the hypothesis.

3. Skip New Relic for this local debugging work — it adds SaaS setup overhead and doesn't give you finer PHP attribution than Blackfire for a single-site WooCommerce hotspot investigation.