Performance Optimization

Overview

AdminLocks is designed to be lightweight. All capability-filtering hooks run only within wp-admin and have zero impact on front-end page loads. For most WordPress sites, AdminLocks adds negligible overhead. This guide covers tuning strategies for high-traffic sites and large multisite networks where every millisecond counts.

Audit Log Storage

High-traffic WordPress admin environments can generate thousands of audit log entries per day, especially when multiple editors and administrators are active. Over time, an unmanaged audit log table can grow large and slow down dashboard queries.

Recommendations for managing audit log size:

• Set the retention period to 30-60 days under AdminLocks > Settings > Audit Log. Older entries are automatically purged via WP-Cron.
• The adminlocks_audit_log table is indexed on created_at and event_type columns for fast query performance.
• For sites that need long-term audit history, sync events to AdminLocks Cloud where they are stored and searchable without impacting your local database size.

Database Queries

AdminLocks adds a minimal number of database queries per admin page load:

Total overhead is 2-3 queries per admin page load. No database queries are made on front-end pages. The capability filtering logic operates entirely in memory once the active policy has been loaded.

Policy Caching

Policies are loaded once per request and cached in the plugin's internal state via $this->active_policies. This means that even if user_has_cap is called dozens of times during a single page load, the policy data is fetched from the database only once.

For sites with object caching enabled, policies are also stored as WordPress transients. This means subsequent requests can retrieve policy data from Redis or Memcached rather than the database, further reducing query overhead.

// Internal caching mechanism (simplified)
if ( $this->active_policies === null ) {
    $this->active_policies = get_transient( 'adminlocks_policies' );
    if ( false === $this->active_policies ) {
        $this->active_policies = $this->load_policies_from_db();
        set_transient( 'adminlocks_policies', $this->active_policies, 300 );
    }
}

The transient TTL is 5 minutes. When you save a policy change, the transient is invalidated immediately so the new rules take effect on the next request.

Snapshot Storage

Snapshots include database exports and can consume significant disk space over time. AdminLocks stores snapshots in the wp-content/adminlocks-snapshots/ directory.

To manage snapshot storage:

• Set a retention period of 30 days or fewer under AdminLocks > Settings > Snapshots.
• Monitor the adminlocks-snapshots/ directory size periodically.
• Old snapshots are automatically cleaned up by a scheduled WP-Cron task.

# Check snapshot directory size
du -sh wp-content/adminlocks-snapshots/

# Manually remove snapshots older than 30 days
find wp-content/adminlocks-snapshots/ -type f -mtime +30 -delete

Cloud Sync Tuning

Audit events are synced to AdminLocks Cloud every 5 minutes via a WP-Cron scheduled task. Events are batched and sent in a single API call to minimize network overhead.

For very high-volume sites that generate hundreds of audit events per hour, consider these adjustments:

• Increase the sync interval to 15 minutes to reduce the frequency of outbound API calls.
• Adjust the batch size to send more events per sync cycle, reducing the total number of API requests.
• Cloud sync is fully asynchronous and does not block or delay admin page loads.

Object Caching

If your WordPress site uses an object caching backend like Redis or Memcached, AdminLocks benefits automatically through the WordPress transients API. No additional configuration is required.

Cached data includes:

• Policy lookups — Active policies are cached with a 5-minute TTL.
• Plugin settings — General settings are cached as autoloaded options.
• Dashboard widget data — Stats queries are cached to avoid repeated aggregation queries.

When you update a policy or change settings, the relevant cache entries are invalidated immediately so changes take effect without waiting for the TTL to expire.

Benchmarks

The following benchmarks were measured on a standard WordPress installation with 20 active plugins, running PHP 8.1 on a cloud VPS with 2 CPU cores and 4GB RAM:

These numbers represent the additional time AdminLocks adds on top of WordPress core processing. In practice, AdminLocks overhead is undetectable in the overall page load time for admin pages.