Every throttle and block decision (and every allowed request, if you enable that) is written to the tg_events table. On a busy site this table grows quickly, so Traffic Guard includes a purge job that deletes old rows.
Running the purge
- Go to Admin > Traffic Guard (
/admin/traffic-guard). - Click Purge Old Logs and confirm.
The job is dispatched through Omeka's job system and runs in the background. Its progress and log output are visible under Admin > Jobs as a TrafficGuard\Job\PurgeTrafficLogs job. When it finishes, the log records how many event rows and how many ban rows were deleted.
Site admins and global admins can run the purge.
What the job deletes
- Event rows older than the Log retention (days) setting (default 30 days). If retention is 0, the job logs that retention is set to keep forever and deletes nothing.
- Ban rows that have been lifted manually (any age).
- Ban rows whose expiry passed more than seven days ago.
Rows are deleted in batches of 1,000, with a cap of 500 batches (500,000 event rows) per run, to avoid holding long table locks. If the cap is reached, run the job again. The job checks for cancellation between batches, so it can be stopped from Admin > Jobs.
Rate-limit counters in tg_rate_windows are not part of this job. They are pruned automatically, a few hundred rows at a time, on about one request in a hundred.
Scheduling the purge
The module does not schedule the job itself. To run it regularly:
- use the AutomationManager module, if installed, to dispatch
TrafficGuard\Job\PurgeTrafficLogson a schedule, or - dispatch it from a cron job using Omeka's job dispatcher in a small PHP script.
Keeping the table small
- Leave Log allowed requests too off unless you are diagnosing a problem. Logging allowed requests adds a row for every page view.
- Lower Log retention (days) if you only need recent history. The dashboard summaries only use the last 24 hours.
- Run the purge after lowering retention; the new value only takes effect when the job runs.