The sf_ocd_itms and sf_ocd_dpdndncies output cache tables grow rapidly (hundreds of thousands to millions of records), causing cache invalidation timeouts, high database CPU utilization, and stale content being served after Site Sync or publishing.

To check the extent of the issue, run the following SQL queries against the Sitefinity database:

-- Total record count

SELECT COUNT(*) FROM sf_ocd_itms;

--Record distribution by status and flags:

SELECT status, flags, COUNT(*) AS RecordCount
FROM sf_ocd_itms
GROUP BY status, flags
ORDER BY RecordCount DESC;

--Top pages by cache entry count (grouped by URL path, excluding query string variations):

SELECT TOP 20
    CASE
        WHEN CHARINDEX('?', url) > 0 THEN LEFT(url, CHARINDEX('?', url) - 1)
        ELSE url
    END AS url_path,
    COUNT(*) AS EntryCount
FROM sf_ocd_itms
GROUP BY
    CASE
        WHEN CHARINDEX('?', url) > 0 THEN LEFT(url, CHARINDEX('?', url) - 1)
        ELSE url
    END
ORDER BY EntryCount DESC;

--If a single page path has thousands of cache entry variations, marketing query string parameters are likely the cause.
--To view the actual query string variations for a specific page, run:

SELECT TOP 50 url, date_modified
FROM sf_ocd_itms
WHERE url LIKE '/your-page-path%'
ORDER BY date_modified DESC;

If a single page URL has thousands of cache entry variations, marketing query string parameters are likely the cause.

When the ASP.NET Core Renderer serves a page, the ExternalCacheMiddleware registers the page URL with the CMS for cache invalidation tracking by calling the restapi/cache/add endpoint. The cache key is computed as a SHA256 hash of the full URL, including all query string parameters.

This means every request with a different tracking parameter value (e.g., utm_source=google vs. utm_source=facebook, or unique ttclid values from TikTok) produces a different SHA256 hash and creates a separate row in the sf_ocd_itms table. A single page receiving traffic from multiple advertising campaigns can accumulate hundreds of thousands of cache entries.

The CMS output cache profile settings (such as IgnoreParams) do not affect this behavior because the entries are created through the Renderer's external cache registration endpoint, which is a separate code path.

Add a query string stripping middleware in the ASP.NET Core Renderer project that removes known marketing/tracking parameters from the request URL before Sitefinity processes it. This ensures the cache key is computed without the tracking parameters.

Add the following middleware in the Renderer's Program.cs, before the Sitefinity middleware:

// Strip marketing query parameters that cause output cache table bloat
var excludedParams = new HashSet<string>(StringComparer.OrdinalIgnoreCase)
{
    "ttclid", "fbclid", "gclid", "msclkid",
    "utm_source", "utm_medium", "utm_campaign",
    "utm_content", "utm_term"
};

app.Use(async (context, next) =>
{
    var query = context.Request.Query;
    if (query.Any(q => excludedParams.Contains(q.Key)))
    {
        var filtered = query
            .Where(q => !excludedParams.Contains(q.Key))
            .ToDictionary(q => q.Key, q => q.Value);

        context.Request.QueryString = QueryString.Create(filtered);
    }

    await next();
});

After deploying the middleware, truncate stale records from the sf_ocd_itms and sf_ocd_dpdndncies tables during off-peak hours:

TRUNCATE TABLE sf_ocd_dpdndncies;
TRUNCATE TABLE sf_ocd_itms;

Monitor the table growth rate after the fix. The record count should stabilize.

The code sample above is provided as guidance and should be tested thoroughly before deploying to production. Add or remove parameters from the excludedParams list as needed for your specific advertising platforms.

Progress Article(s):

1. Cache: Performance degradation caused by rapidly growing output cache tables