Micator performance on 2/4 and 4/8 servers

Load and performance

Click, postback and report measurements on 2 vCPU / 4 GB and 4 vCPU / 8 GB servers, test conditions and practical sizing guidance.

These measurements were taken on two real VPS instances on October 14, 2026. They describe specific workloads, not a guaranteed rate for every server with the same RAM. See server requirements for installation prerequisites.

Planning headroom

Server	Simple redirects	Offer rotation and click caps
2 vCPU / 4 GB	Start around 500–1,000 clicks/s	Start around 250–500 clicks/s
4 vCPU / 8 GB	Start around 1,000–2,000 clicks/s	Start around 500–1,000 clicks/s

These are starting points with headroom below tested short peaks. Watch the statistics queue, click latency, CPU, available memory and report response times. Do not extrapolate a minute-long test into a promise of the same rate all day: data size, disk conditions and background activity change over time.

Test conditions

Two Ubuntu 24.04 amd64 VPS instances with KVM virtual CPUs: 2 CPUs / 3,915 MiB and 4 CPUs / 7,941 MiB; no swap.
Click-path Go source from release 20261013.8, PostgreSQL 16, ClickHouse 24.8 and Redis 7, with reduced ClickHouse diagnostic logging. Binaries were built from that release source; this is not a benchmark of the installer archive's code protection.
Separate disposable databases, networks and containers; existing installations stayed running. These results are not a whole-machine maximum on an otherwise empty host.
Test container memory limits: ClickHouse 1,200 MiB, Redis 512 MiB, PostgreSQL and each Go service 256 MiB. Both VPS instances used this same test profile.
Simple workload: click → disk journal → HTTP 302 to one offer. Complex workload: three offers, unvisited rotation and click-cap checks.
Requests go directly to the test redirect, without Cloudflare or public HTTPS. The generator does not follow the offer URL. PHP pages, file uploads, external APIs and full GeoIP-based filtering are outside this test.
Each step compares accepted click IDs with stored ClickHouse rows, visitor attribution, costs and report totals. Complex workloads request a report every five seconds and check fresh postbacks during traffic.

Short load steps

Each step lasts 60 seconds. The generator runs on the tested VPS and its CPU is part of host load. p95 means 95% of requests complete within that time; p99 means 99%. Latency starts at the scheduled request time and includes generator queueing.

Server	Scenario	Offered clicks/s	Accepted clicks/s	p95 / p99, ms	Statistics catch-up, s
2 / 4	Redirect	250	250	38 / 110	0.4
2 / 4	Redirect	500	500	40 / 113	0.5
2 / 4	Redirect	1000	1000	50 / 119	0.5
2 / 4	Redirect	2000	2000	171 / 269	1.6
2 / 4	Redirect	3000	2985	413 / 591	0.6
2 / 4	Redirect	4000	3376	9975 / 11179	1.6
2 / 4	Rotation + caps	250	250	29 / 82	1.5
2 / 4	Rotation + caps	500	500	26 / 48	0.5
2 / 4	Rotation + caps	1000	1000	77 / 147	0.5
2 / 4	Rotation + caps	1500	1495	571 / 889	0.5
4 / 8	Redirect	500	500	53 / 126	0.6
4 / 8	Redirect	1000	1000	49 / 115	1.6
4 / 8	Redirect	2000	1999	78 / 164	0.6
4 / 8	Redirect	3000	2997	106 / 186	0.7
4 / 8	Redirect	5000	4970	334 / 499	0.8
4 / 8	Redirect	6000	5976	1517 / 1655	7.3
4 / 8	Rotation + caps	500	500	57 / 119	1.6
4 / 8	Rotation + caps	1000	1000	44 / 110	0.6
4 / 8	Rotation + caps	2000	1997	108 / 158	0.6
4 / 8	Rotation + caps	3000	2987	1533 / 1652	0.6

At 1,500 clicks/s with rotation on 2/4, p99 approached 0.9 seconds. At 3,000 clicks/s with rotation on 4/8, p99 exceeded 1.5 seconds and the ladder stopped. At 4,000 simple redirect clicks/s on 2/4, request queueing pushed p99 to 11.2 seconds and achieved throughput was about 3,400/s. At 6,000 clicks/s on 4/8, p99 reached 1.66 seconds and the statistics backlog reached about 58,000 clicks at the end of traffic; writing caught up in another 7.3 seconds. Even without lost records, this reduces responsiveness and leaves less capacity for the panel.

Five minutes of sustained load

Each listed workload ran for 300 seconds with the same colocated generator. This verifies sustained traffic over five minutes; it does not establish a multi-day capacity limit.

Server	Scenario	Offered clicks/s	Accepted clicks/s	p95 / p99, ms	Statistics catch-up, s
2 / 4	Redirect	1000	1000	72 / 138	1.6
2 / 4	Rotation + caps	500	500	54 / 126	1.5
4 / 8	Redirect	2000	2000	84 / 156	0.7
4 / 8	Rotation + caps	1000	1000	71 / 150	0.6

Accepted and stored click IDs are reconciled after each step. Statistics catch-up is the measured time to finish writing after traffic stops; it is not click loss.

Postbacks and reports

Each VPS also received batches of 4, 16 and 32 concurrent postbacks with transaction identifiers. All were accepted, without duplicate conversions. With 32 concurrent postbacks, the slowest response took 0.75 seconds on 2/4 and 0.58 seconds on 4/8. The panel remained responsive. A separate concurrent test on both servers stopped the capped offer at exactly 20,000 clicks; its counter matched stored clicks.

On the existing 2/4 installation with 483 campaigns and 1.23 million imported clicks, an all-history campaign report had a median response time of about 0.7 seconds. This was read-only access to existing history; synthetic clicks were not inserted into it. Concurrent heavy reports and other dimensions may take longer.

Idle resource use

In one-minute measurements, host CPU at idle fell from 22% to 5.6% on 2/4 and from 8.7% to 4.3% on 4/8 after changing ClickHouse logging. Warnings, errors and query diagnostics remain; continuous detailed profiling is disabled and metrics are written less often. Lower background CPU does not imply the same speedup for every report.

If the panel feels slow, check free disk space, available RAM, the statistics queue, background migrations and backups. Compare opening the panel without reports with a long reporting period, then address the measured bottleneck. Load testing should use separate test campaigns and isolated data.

Continue with server requirements, statistics retention and backups.

Updated October 13, 2026Need help? ↗