CAPTCHA-Lösungsleistung nach Region: Latenzanalyse

Ein Worker in Frankfurt zahlt pro Lösung rund 0,5 Sekunden mehr Netzwerk-Overhead als einer in Virginia – bei 20.000 Lösungen im Monat knapp drei Stunden Wartezeit. An der Verarbeitungszeit bei CaptchaAI ändert der Standort nichts; teuer ist allein der Weg hin und zurück. Dieser Artikel beziffert den Aufschlag und nennt fünf Hebel dagegen.

Latenz-Overhead nach Serverregion

Eine Lösung besteht aus 5–7 Roundtrips: Übermittlung plus Statusabfragen. Jede Millisekunde Round-Trip-Time (RTT) zählt also mehrfach.

Hinweis: Die Werte stammen aus internen Messungen; Routing und Peering verschieben sie in beide Richtungen. Frankfurt, Falkenstein oder Wien liegen im moderaten Bereich – spürbar, aber kompensierbar.

Woraus sich die Lösungszeit zusammensetzt

Gesamtlösungszeit = Verarbeitungszeit bei CaptchaAI + Netzwerklatenz × Roundtrips. Nur der zweite Summand liegt in Ihrer Hand:

• Verarbeitung bei CaptchaAI: je nach Typ unter 0,5 s (Bild) bis unter 60 s (reCAPTCHA v2) – nicht beeinflussbar.
• Netzwerklatenz je Roundtrip: 5–300 ms, abhängig vom Standort des Workers.
• DNS-Auflösung: 5–200 ms beim ersten Aufruf, per DNS-Caching vermeidbar.
• TLS-Handshake: 30–100 ms je Verbindungsaufbau, per Keep-Alive vermeidbar.

RTT messen statt schätzen

Das Skript wärmt die Verbindung auf und misst 20 Aufrufe gegen res.php. Median und P90 sagen mehr als ein Ping.

Schnelltest

# measure_latency.py
import os
import time
import requests
import statistics

API_KEY = os.environ.get("CAPTCHAAI_KEY", "YOUR_API_KEY")

session = requests.Session()

# Warm up connection (TLS + DNS)
session.get("https://ocr.captchaai.com/res.php", params={
    "key": API_KEY, "action": "getbalance", "json": "1",
})

# Measure latency over 20 calls
latencies = []
for i in range(20):
    start = time.time()
    session.get("https://ocr.captchaai.com/res.php", params={
        "key": API_KEY, "action": "getbalance", "json": "1",
    })
    latency = (time.time() - start) * 1000
    latencies.append(latency)

print(f"Median RTT: {statistics.median(latencies):.0f}ms")
print(f"P90 RTT: {sorted(latencies)[int(len(latencies)*0.9)]:.0f}ms")
print(f"Min: {min(latencies):.0f}ms, Max: {max(latencies):.0f}ms")

# Estimate per-solve overhead (6 round trips typical)
median_overhead = statistics.median(latencies) * 6
print(f"\nEstimated per-solve overhead: {median_overhead:.0f}ms")

Rechnen Sie den Median mal sechs – so groß ist der Aufschlag pro Lösung. Über 500 ms lohnt sich einer der folgenden Hebel.

Fünf Hebel gegen regionale Latenz

1. Verbindungen mit Keep-Alive offen halten

Ohne Keep-Alive zahlen Sie DNS-Auflösung und TLS-Handshake bei jedem Aufruf erneut. Eine wiederverwendete Session spart 100–300 ms beim Verbindungsaufbau.

session = requests.Session()
session.headers.update({"Connection": "keep-alive"})

2. Polling-Intervalle an den CAPTCHA-Typ anpassen

Jede Statusabfrage ist ein Roundtrip. Wer zu früh und zu oft abfragt, zahlt die Latenz mehrfach. Bewährte Startwerte:

Eine längere erste Wartezeit spart zwei bis drei Abfragen.

3. Callback-URL statt Polling

Mit einer Pingback-URL entfallen die Abfrage-Roundtrips: Sie übermitteln die Aufgabe, CaptchaAI schickt das Ergebnis per POST an Ihren Endpunkt.

# Submit with callback — zero polling round trips
resp = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY,
    "method": "userrecaptcha",
    "googlekey": "SITEKEY",
    "pageurl": "https://example.com",
    "pingback": "https://your-server.com/captcha-callback",
    "json": "1",
})
# CaptchaAI will POST the result to your callback URL
# Total round trips: 1 (submit only)

Voraussetzung ist ein öffentlich erreichbarer Endpunkt für den Webhook.

4. Worker näher an den Endpunkt legen

Ist die Latenz das Nadelöhr, verlagern Sie die Worker in den Osten der USA; die RTT fällt unter 30 ms. Prüfen Sie vorher, ob Ihre DSGVO-Anforderungen einen Verarbeitungsstandort außerhalb der EU zulassen.

5. Die Lösung parallel zum Seitenaufbau starten

Übermitteln Sie die Aufgabe, sobald klar ist, dass die Seite ein CAPTCHA verlangt – nicht erst beim Absenden. Legen Sie Token aber nicht auf Vorrat an: Ein reCAPTCHA-Token gilt nur rund 120 Sekunden.

Rechenbeispiel: Crawler auf einem Frankfurter Server

Ein Team löst mit seinem Crawler auf einem VPS in Frankfurt 40.000 reCAPTCHA v2 pro Monat, angestoßen aus einer GitLab-CI-Pipeline. Bei 100 ms RTT und sechs Roundtrips sind das rund 600 ms Overhead pro Lösung – etwa 6,7 Stunden Wartezeit im Monat.

Zwei Änderungen genügen: Keep-Alive in der Session und der Wechsel von 3-Sekunden-Polling auf 15 s erste Wartezeit plus 5-Sekunden-Intervall. Die Roundtrips sinken von sechs auf vier, der Overhead auf 400 ms – ohne den Server aus Deutschland zu verlagern.

Was die Architektur daran ändert

• Ein Server, sequenziell: voller Overhead je Lösung – Keep-Alive und Callback.
• Ein Server, parallel: Overhead verteilt sich über gleichzeitige Lösungen.
• Multi-Region-Deployment: zum nächstgelegenen Worker routen.
• Serverless (Lambda, Cloud Functions): Kaltstart plus DNS je Aufruf – Provisioned Concurrency, feste Region.
• Edge-Worker (Cloudflare Workers): regionsabhängig – Callback-URL nutzen.

Häufige Fragen

Gibt es CaptchaAI-Endpunkte in Europa?

Nein, alle Anfragen laufen über dieselben Endpunkte. Ihre Latenz ergibt sich aus Serverstandort und Provider-Routing.

Ist die Verarbeitung in Asien langsamer?

Nein. Die Verarbeitungszeit hängt am CAPTCHA-Typ, nicht am Standort – regional unterscheidet sich nur der Netzwerkweg.

Bleibt ein Token bei hoher RTT gültig?

Ja, solange Sie es zügig einsetzen. Ein reCAPTCHA-Token gilt rund 120 Sekunden – ein bis zwei Sekunden Overhead sind unkritisch, ein altes Token wertlos.

Wie viele Lösungen laufen parallel?

Das regelt Ihre Thread-Anzahl, nicht die Region: CaptchaAI rechnet pro gleichzeitigem Thread ab, mit unbegrenzten Lösungen je Thread; BASIC beginnt bei 15 $ im Monat mit 5 Threads.

Verwandte Leitfäden

• Schnellstart: erster API-Aufruf
• Antwortformate und Fehlercodes
• reCAPTCHA v2 per API lösen