Performance Profiler

PetMatchPro ships a lightweight request profiler that writes coarse server-side timing lines to the PHP error log. Use it when a search page renders slowly and you need to see where the time goes – the API fetch, the card loop, a theme or third-party the_content filter running after the shortcode, or something else. It is a diagnostic aid, available on every license tier, that adds no markup and no measurable overhead when it is off.

The profiler is deliberately hard to turn on by accident: it logs nothing unless all three conditions below are met at once, so a visitor cannot trigger logging by guessing a query string.

Enable It (wp-config.php) #

Add this line to wp-config.php, above the /* That's all, stop editing! */ comment:

define( 'PMP_PROFILE', true );

Defining the constant alone logs nothing. It is one of three required conditions:

1. PMP_PROFILE is defined as exactly true.
2. You are logged in as a user who can manage_options (an administrator).
3. The URL you load carries ?pmp_profile=1.

Because an administrator is required, the profiling request always fetches live animal data – admins bypass the plugin’s API cache – so the reported fetch time is a live partner-API call, not a cache read. The rendered HTML is byte-identical whether the profiler is active or not.

Run It #

While logged in as an administrator, open the search page you want to measure and add ?pmp_profile=1 to its URL (use &pmp_profile=1 if the URL already has a query string):

https://example.org/adopt/dogs/?pmp_profile=1

Load the page normally. The profiler writes its lines as the request runs. Reload a few times to get a representative set – the first load after a code change or a cache clear is often slower than steady state.

Where the Log Lands #

The profiler writes with PHP’s error_log(). Where that goes depends on your setup:

• If WP_DEBUG_LOG is true, lines land in wp-content/debug.log.
• Otherwise they go to your host’s PHP error log.

Host-specific locations:

• Kinsta: MyKinsta > your site > Logs (choose the error log), or logs/error.log over SSH/SFTP.
• LiteSpeed / InterServer and most cPanel hosts: the PHP error log, usually surfaced in the host control panel’s Logs or Errors section, or an error_log file in the site root.

Every line this profiler writes is prefixed [PMP Profile], so you can isolate them:

grep "\[PMP Profile\]" wp-content/debug.log

Reading the Output #

Each line starts with the prefix, a six-character request id, and the page path, so lines from one page load group together and concurrent requests do not mix:

[PMP Profile] a1b2c3 /adopt/dogs/ ...

There are two kinds of line.

Milestones report the time in milliseconds since the request started, one per WordPress assembly step – for example init, wp, template_redirect.start/.end, wp_head.start/.end, content.start, content.after11 (after shortcodes run), content.end, pmp-search.start/.end, pmp-details.start/.end, wp_footer.start/.end, and shutdown.start. One line lists every the_content callback as priority:name, and an extra content.afterPrio.N milestone is logged after each callback that runs at priority 11 or higher. A long gap between content.after11 and a content.afterPrio.N line names the filter that is slow – this is exactly how the 8.25 slowdown (WordPress core rewriting the page once per image) was found.

The search line is one summary per [pmp-search] render, with coarse segments:

[PMP Profile] a1b2c3 /adopt/dogs/ search partner=AF method=lost_found cards=936 cache=bypass total=3180.4 | fetch=1850.2 | prepare=120.5 | cards=980.1 | after=60.3 | unaccounted=169.3

• partner / method / cards – which partner rendered, the method type, and how many cards were built.
• cache – hit, miss, or bypass. Because profiling requires an administrator, and admins bypass the API cache, this reads bypass and fetch is a live partner call. Non-admin visitors (who cannot profile) are the ones who get hit/miss.
• fetch – the API fetch (or cache read), including pagination and sort.
• prepare – sort/filter/field preparation before the card loop.
• cards – the template render (the per-card loop).
• after – everything after the loop (poster bar, size overrides, wrap-up).
• unaccounted – wall time inside the profiled span not captured by a named segment.

Turn It Off #

Remove the define( 'PMP_PROFILE', true ); line from wp-config.php. The profiler stops immediately on the next request. There is no admin setting and no other switch to reset. On a busy site, remember that debug.log is not rotated automatically – see Reading PMP Debug Logs.

Related #

• Performance and Caching Best Practices – the caching layers the fetch segment measures.
• Reading PMP Debug Logs – where logs land and how to grep them.
• wp-config.php Configuration Constants – PMP_PROFILE and other operator toggles.