We tested the Binom v2 (2.35.03) and Keitaro (11.10.0) trackers under increasing load, separately tested a non-standard scenario, and compared how they handled real traffic.

Test Results

In synthetic tests, Binom handled a higher load. The highest tested load-test tier that the trackers sustained for three minutes without errors was 480 requests/sec for Binom and 80 requests/sec for Keitaro. At the same load of 160 requests/sec, average CPU utilization was 24.42% for Binom and 82.90% for Keitaro.

With a large number of repeat requests from the same visitor (non-unique clicks), Keitaro began to slow down and return errors. At just 80 requests/sec, all requests ended in timeouts or HTTP 500 errors. Binom passed a similar test at 80 requests/sec without errors. When overloaded, Keitaro also affected a neighboring campaign, although the admin panel remained accessible.

On real popunder traffic, no advantage was found for either tracker: 92.20% of Keitaro assignments and 91.85% of Binom assignments reached the checkpoint.

CPA.RIP editorial opinion: 

If you do not have a very large traffic volume, you can use either tracker without issues. If you experience spikes, Binom is worth choosing. Unexpectedly, Keitaro showed a strange bug with non-unique clicks, which essentially makes it possible to “silence” any tracker. We tested and retested it three times. All details are below.

Popular CPA trackers for affiliate marketing: https://cpa.rip/services/cpa-trackers/.

Test Setup and Methodology

For load testing, we used the k6 tool, which generates a stream of requests to the tracker, measures response time, and records errors. We increased the load in tiers with a gradual 30-second ramp-up and held each level to measure the results.

We set the same 5-second timeout per request for both trackers. If no response arrived within that time, k6 stopped waiting and recorded a timeout. All requests, including those ending in an error or timeout, were included in the p95 and p99 calculations. 

p95 and p99 are response-time percentiles, meaning the values within which 95% and 99% of requests are completed. For example, p95 = 526 ms means that 95% of requests completed in 526 ms or faster, while 5% were slower. p99 = 770 ms means that 99% of requests completed within 770 ms. This makes it possible to show slow responses that the average time hides.

Both trackers were installed on identical VPSs from FriendHosting: 4 vCPU and 4 GB RAM. CentOS Stream 9 for Keitaro and Ubuntu 24.04 for Binom.

We ran the main load tests sequentially: to test Keitaro, we launched the k6 generator on the Binom server, and vice versa for testing Binom.

For the real popunder traffic test, we used a third server (a VPS with 2 vCPU and 2 GB RAM). It distributed incoming visits between the trackers and recorded whether they passed through a checkpoint after the redirect.

Increasing Load Until Errors Occurred (Unique Clicks)

For Keitaro, we increased the load from 20 to 320 requests/sec and held each tier for three minutes. At 80 requests/sec, all 14,400 requests received the correct redirect and were saved in the database. At 160, timeouts appeared, and at 320 there were no longer any correct redirects, while average CPU utilization reached 93.79%; the log recorded a handler queue overflow. 

The overload also affected a neighboring campaign: 31 of 156 verification requests ended in an error or timeout. The admin panel remained functional. After reducing the load to 20 requests/sec, 6,000 correct redirects were received without errors over five minutes, with p99 at 33 ms.

Binom returned all 86,400 correct redirects at the 480 requests/sec tier and saved all clicks, with p99 at 657 ms. At 640 requests/sec, all 115,384 started requests were saved, but 11 ended in 5-second timeouts.

At 800-960 requests/sec, mass HTTP 502 errors and timeouts appeared. Later, the traffic-processing container reached its standard 2 GB memory limit set in the configuration and restarted.

After reducing the load to 20 requests/sec, 2,400 correct redirects and the same number of database records were received over two minutes, with p99 at 7 ms.

Nuance: Repeat Visits From One Visitor

By default, Keitaro campaign uniqueness was determined by the IP + UA combination over a 24-hour period. In preliminary tests, k6 used one IP and a constant User-Agent, so thousands of requests were identified as repeat visits from one person, causing a sharp slowdown. Although this scenario is unlikely under real conditions, we tested it separately on both trackers.

We increased the load in three-minute tiers with gradual 30-second transitions. Keitaro handled 40 requests/sec without errors at average CPU utilization of 74.26%. The first timeouts appeared when moving to 80 requests/sec, and at the 80 requests/sec tier itself, all requests ended in a timeout or HTTP 500 error.

At 80 requests/sec, the CPU was almost fully occupied. The Keitaro log showed the error static_pool_exec: QueueSize: max queue size reached – the request queue reached its maximum size, and the handler began rejecting new requests. All timed-out requests were saved, while all 4,578 HTTP 500 requests were absent from the database.

During this load, the neighboring campaign that we were testing in parallel was also affected. During the test, 55 of 136 probes were unsuccessful. The admin panel remained accessible.

In the same test, Binom processed all 14,401 repeat requests without errors and saved every click. 

Testing on Real Popunder Traffic

After the k6 runs, we tested the trackers on purchased popunder traffic from the MyBid network. A separate technical server randomly distributed the incoming flow between them with a 50/50 probability.

MyBid → distributor → Keitaro or Binom → checkpoint → affiliate page.

The promo code CPARIP gives you a 15% bonus on your first balance top-up from $100 to $3000 in the MyBid ad network.

The distributor received 24,729 requests. Each visit was assigned its own event_id. We used it to match the distributor record, the click in the tracker database, and arrival at the checkpoint.

How Much Traffic Arrived From the Ad Network

This is the difference between the ad network’s counter and our distributor’s counter before the trackers.

How Many Visits Passed Through the Trackers

Traffic arrived for about nine hours, with a peak of 9 incoming requests per second across both branches combined. A total of 22,757 visits reached the checkpoint. All of them were found in the databases of their respective trackers. Of the 1,972 visits that did not arrive, 628 were saved in the databases and 1,344 were not.

Both trackers counted both unique and repeat clicks. About 4% of clicks were counted as repeat clicks:

In the main table, several records with the same event_id are combined into one visit. The uniqueness table shows all tracker records, so the final figures are slightly higher.

Comparison Result

In intermediate snapshots, Binom led in the share of visits that reached the checkpoint, but by the final snapshot Keitaro held a small advantage.

Ultimately, both trackers showed a similar share of visits reaching the checkpoint, about 92% of assignments. This result complements the load tests and shows how the overall setup performs on purchased popunder traffic, but it does not allow either tracker to be called more reliable than the other based on the share of visits that arrived.

The promo code CPARIP gives you 30 days of trial access to the Binom tracker at no cost. After the trial, the promo code CPARIP gives you a 40% discount on the first payment for a Binom license on your own server.