Proxy-Abrechnung pro Anfrage

Wofür Sie bezahlen

Sie bezahlen die vom Anbieter gezählte Anzahl von Anfragen. Er kann feste Pakete verkaufen oder nach Verbrauch abrechnen. Preise werden häufig pro tausend oder pro Million Anfragen angegeben. Das erleichtert den Tarifvergleich, zeigt aber nicht den erforderlichen Kaufbetrag: Das kleinste Paket kann mehr Anfragen enthalten.

Dasselbe Wort „Anfrage“ kann unterschiedliche Dienste beschreiben. Ein gewöhnlicher Proxy leitet Anfragen Ihrer Anwendung an Websites weiter und liefert deren Antworten zurück. Ihre Anwendung lädt die Seiten und extrahiert Daten. Bei einer Datenerfassungs-API kann der Preis auch Browserbetrieb, die Behandlung von Zugriffsbeschränkungen und die Aufbereitung der Ergebnisse enthalten. Der Anfragepreis allein reicht deshalb nicht zum Vergleich; Sie müssen wissen, welche Arbeit der Dienst dafür übernimmt.

Diese Abrechnung ist praktisch für planmäßige Arbeit. Vielleicht kennen Sie bereits die Zahl der zu prüfenden Seiten und die Häufigkeit. Ermitteln Sie anschließend die Anfragen pro Prüfung. Dann können Sie das benötigte Monatspaket und den Mehrverbrauch durch zusätzliche Seiten schätzen.

Die Antwortgröße beeinflusst den Preis nicht zwangsläufig. Berechnet der Tarif jede Anfrage gleich, kann der Abruf vieler Daten in einer Antwort genauso viel kosten wie eine kleine Antwort. Prüfen Sie aber den Leistungsumfang: Bandbreite, Antwortgröße oder Ausführungszeit können begrenzt sein. Zusätzliche Datenverarbeitung kann separat berechnet werden.

Ein Anfragepaket bestimmt nicht die Anzahl erhaltener IP-Adressen. Ein rotierender Dienst kann beispielsweise über einen gemeinsamen Endpunkt Zugang zu einem IP-Pool bieten. IP-Wechsel und das Beibehalten einer Adresse für eine Sitzung hängen von den Diensteinstellungen ab. Ein IP-Wechsel allein verrät nicht, wie viele Anfragen berechnet werden.

Was der Dienst als eine Anfrage zählt

Unterscheiden Sie zuerst Anfrage und Verbindung. Eine HTTP-Anfrage fordert eine Website zu etwas auf, etwa zur Rückgabe einer Seite oder von Daten. Die Website sendet eine Antwort. Datenverkehr in beide Richtungen bedeutet allein nicht, dass zwei Anfragen abgezogen werden müssen. Dafür wäre eine separate Abrechnungsregel nötig.

Eine Verbindung ist der Kanal, über den die Anwendung mit dem Server kommuniziert. Mehrere Anfragen können dieselbe Verbindung nutzen. HTTP/1.1 erlaubt die Wiederverwendung; HTTP/2 ermöglicht mehrere gleichzeitige Austausche darüber. Anfragezahl, geöffnete Verbindungen und gleichzeitig aktive Verbindungen sind daher unterschiedliche Messgrößen.

HTTPS bringt ein weiteres Detail hinzu. Bei einem HTTP-Proxy sendet die Anwendung üblicherweise einen CONNECT-Befehl, um einen Tunnel zur Website aufzubauen. Spätere Anfragen laufen darin verschlüsselt. Der Proxy leitet die Daten weiter, kann aber bei gewöhnlicher Nutzung die einzelnen HTTP-Anfragen nicht lesen. Auch ein SOCKS-Proxy stellt eine Verbindung zum Ziel bereit; nicht jede Anwendungsaktion benötigt eine neue Verbindung.

Deshalb bezeichnen manche Dienste eine Verbindung oder ein anderes vom Proxyserver zählbares Ereignis als „Anfrage“. Andere zählen einzelne HTTP-Anfragen oder API-Aufrufe. Die Anfragezahl in den Browser-Entwicklerwerkzeugen kann daher vom Verbrauch im Anbieter-Dashboard abweichen. Die Unterstützung von HTTP, HTTPS oder SOCKS5 allein legt die Zählregel nicht fest.

Führen Sie vor dem Kauf eines großen Pakets einen kleinen Test aus. Erfassen Sie die abgeschlossenen Aufgaben und die vom Dienst abgezogenen Anfragen. Verwenden Sie dieselbe Anwendung, dasselbe Protokoll und dieselben Einstellungen wie später. Ein Test mit einem einfachen HTTP-Client zeigt nicht den Verbrauch eines Browsers, der zusätzlich Skripte und andere Seitenressourcen lädt.

Warum eine Seite mehrere Anfragen verbrauchen kann

Zum Öffnen einer Seite wird oft mehr als das Hauptdokument benötigt. Der Browser lädt Stylesheets, Skripte, Bilder und Daten separat. Eine geöffnete Seite kann den Server weiter für Aktualisierungen kontaktieren. Je nach Anwendungseinstellungen laufen auch einige dieser Anfragen durch den Proxy. Ihre Berechnung hängt vom Tarif ab.

Eine Weiterleitung erzeugt eine weitere Anfrage. Meldet die Website eine andere Seitenadresse, sendet eine entsprechend konfigurierte Anwendung eine weitere HTTP-Anfrage dorthin. Ein Dokument mit einem einfachen Client abzurufen und die vollständige Seite im Browser zu öffnen kann daher unterschiedlich viele Anfragen benötigen. Die URL-Anzahl Ihrer Liste zeigt noch nicht den Verarbeitungsverbrauch.

Eine API kann umgekehrt arbeiten: Eine Anfrage kann viele Datensätze abrufen. Im Beispiel sendet ein Browser fünf Anfragen, um eine Kopfhörer-Produktseite samt Preis zu laden. Eine Anwendung nutzt denselben Proxy für die Katalog-API dieses Händlers und erhält fünf Produktpreise mit einer Anfrage. Gemeint ist die API des Händlers, die Produktdaten liefert. Gibt sie den Katalog seitenweise aus, benötigt jede Seite eine weitere Anfrage. Mitunter lässt sich die Produktanzahl pro Antwort erhöhen, sofern die API diese Einstellung unterstützt und alle benötigten Daten zurückgibt.

So lässt sich mehr nützliche Arbeit aus einem Paket gewinnen. Wiederholtes Laden ganzer Seiten, erneutes Abrufen bereits gespeicherter Daten und unnötig häufige Preisprüfungen können das Kontingent schnell verbrauchen. Mehrere Produkte pro Aufruf, gespeicherte Ergebnisse und eine passende Prüfhäufigkeit reduzieren die Anfragen für dieselbe Aufgabe. Bei gleicher Last reicht das Kontingent innerhalb seiner Gültigkeit länger; alternativ können Sie damit mehr Produkte prüfen.

Messen Sie den Verbrauch pro abgeschlossener Aufgabe. Das kann die Prüfung einer Seite, der Abruf einer vollständigen Liste oder die Prüfung eines erst nach Skriptausführung sichtbaren Elements sein. Messen Sie den ganzen dafür nötigen Ablauf einschließlich zusätzlicher Seitenabrufe, die beim Zählen der Start-URLs leicht übersehen werden.

Wo dieses Preismodell sinnvoll ist

Planmäßiges Monitoring

Der Anfrageverbrauch lässt sich an regelmäßige Prüfungen binden. Eine Anwendung überwacht etwa Seitenverfügbarkeit, Änderungen öffentlicher Einträge oder Suchergebnisse für eine bestimmte Region. Zielanzahl und Prüfhäufigkeit stehen im Voraus fest. Ein Test zeigt die Anfragen pro Prüfung und hilft, den Monatsverbrauch zu schätzen.

Nicht alle Seiten müssen gleich häufig geprüft werden. Ändern sich Informationen einmal täglich, liefern minütliche Prüfungen meist dieselben Daten. Häufigere Prüfungen können Seiten vorbehalten bleiben, bei denen Änderungen schnell erkannt werden müssen. So bleibt das Paket für benötigte Beobachtungen verfügbar.

Datenerfassung über APIs und Verzeichnisse

Hier hängt der Verbrauch davon ab, wie die Website ihre Informationen bereitstellt. Enthält die Liste bereits alle benötigten Angaben, müssen Sie nicht jede Detailseite öffnen. Zusätzliche Anfragen können Einträgen mit fehlenden Daten oder seit dem letzten Lauf geänderten Datensätzen vorbehalten bleiben. Je mehr benötigte Daten ein Aufruf liefert, desto weniger Anfragen braucht die gesamte Erfassung.

Berücksichtigen Sie auch die Leistung des Dienstes. Eine Such-API kann aufbereitete Ergebnisse liefern; ein gewöhnlicher Proxy überlässt Download und Verarbeitung Ihrer Anwendung. Das sind unterschiedliche Arbeitsumfänge. Prüfen Sie beim Preisvergleich den Antwortinhalt und die verbleibende Eigenarbeit.

Website-Audits und Browserprüfungen

Ein technisches Audit hat häufig einen klaren Ablauf: Adresse öffnen, Antwort prüfen, gegebenenfalls einer Weiterleitung folgen und Ergebnis speichern. Werden die meisten Adressen ähnlich verarbeitet, erleichtert ein Test die Verbrauchsschätzung. Eine Browserprüfung kann wegen benötigter Skripte, Bilder und funktionierender Seitenelemente mehr Anfragen verlangen.

Wählen Sie die Prüfmethode nach dem Zweck. Um zu sehen, ob eine Seite antwortet, reicht oft ein einfacher Client. Ein Checkout-Formular muss dagegen mit seinen benötigten Ressourcen geladen werden. Das Abschalten erforderlicher Dateien senkt die Anfragezahl, aber der Test zeigt dann nicht mehr die Nutzererfahrung.

Wie Fehler und Wiederholungen den Verbrauch beeinflussen

Eine gesendete Anfrage liefert nicht immer die benötigten Daten. Eine Website kann einen Fehler, eine Zugriffsprüfung oder eine andere Seite zurückgeben. Selbst HTTP 200 garantiert nicht den gewünschten Inhalt: Der Status meldet Erfolg auf HTTP-Ebene, während der Antwortinhalt separat geprüft werden muss.

Die Abrechnungsregeln unterscheiden sich. Manche Dienste zählen gesendete Anfragen. Andere berechnen nur Antworten, die ihrer Definition eines erfolgreichen Abschlusses entsprechen. Eine verwaltete API kann mehrere interne Abrufversuche im Preis einer Antwort einschließen. Zusätzliche Modi oder Funktionen ändern mitunter die Abrechnung. „Pro Anfrage“ bedeutet deshalb nicht automatisch „nur für erhaltene Daten bezahlen“.

Ein Wiederholungsversuch Ihrer Anwendung unterscheidet sich von einem Versuch innerhalb des Dienstes. Sendet die Anwendung erneut, erzeugt sie eine neue Anfrage. Wiederholt der Dienst eine bereits übermittelte Aufgabe, können diese Versuche enthalten sein. Klären Sie, welche Versuche vom Paket abgezogen werden.

Erfassen Sie im Test drei Zahlen: gestartete Aufgaben, berechnete Anfragen und abgeschlossene Aufgaben. Der Abschluss hängt vom Zweck ab. Bei der Datenerfassung muss die Antwort die benötigten Felder und ausreichend aktuelle Informationen enthalten. Beim Verfügbarkeitsmonitoring ist auch die korrekte Feststellung einer unerreichbaren Website eine abgeschlossene Prüfung.

Diese Zahlen zeigen die tatsächlichen Arbeitskosten. Günstige Anfragen können unwirtschaftlich sein, wenn Antworten ständig wiederholt oder verworfen werden müssen. Ein teurerer Dienst übernimmt möglicherweise einen Teil der Arbeit. Vergleichen Sie die Ausgaben für das benötigte Ergebnis einschließlich der Arbeit, die Ihrer Anwendung bleibt.

So berechnen Sie das benötigte Paket

Zählen Sie zunächst die geplanten Vorgänge: Wie viele Ziele müssen wie oft verarbeitet werden? Ergänzen Sie Anfragen über den normalen Abruf hinaus, etwa im Test beobachtete Wiederholungen. Berechnen Sie unterschiedlich reagierende Seitengruppen getrennt. Halten Sie eine Wachstumsreserve ebenfalls separat, damit zusätzliche Anfragen nicht doppelt angesetzt werden.

Ein Beispiel: Eine Anwendung prüft 150 URLs alle 30 Minuten über 30 Tage. Wir nehmen an, dass eine normale Prüfung im gewählten Tarif eine Anfrage verbraucht und zusätzliche Versuche den Verbrauch um 5 % erhöhen. Alle Zahlen und Preise sind hypothetisch; es sind keine Anbietertestergebnisse und kein ProxyCompass-Tarif.

Das gewählte Paket lässt eine Reserve von 23.200 Anfragen. Sie kann Mehrarbeit innerhalb der Paketgültigkeit abdecken. Erwartete Wiederholungen sind bereits in den 10.800 zusätzlichen Versuchen enthalten; dieselben Wiederholungen dürfen nicht erneut als Verbrauch dieser Reserve gezählt werden.

Das Paket koste 10 $. Es enthält 250 Tausend Anfragen; der rechnerische Preis pro tausend beträgt somit 0,04 $. Für das ganze Paket zahlen Sie 10 $. Multipliziert man den erwarteten Verbrauch von 226.800 Anfragen mit diesem Satz, erhält man 9,072 $. Das ist der Wert des verbrauchten Anteils, nicht der Kaufbetrag: Das feste Paket kostete weiterhin 10 $.

Nach den zusätzlichen Versuchen schließe die Anwendung alle 216.000 geplanten Prüfungen ab. Tausend abgeschlossene Prüfungen kosten rund 0,0463 $: 10 $ ÷ 216.000 × 1.000. Dieser Betrag berücksichtigt Zusatzanfragen und die gekaufte Reserve. Werden weniger Prüfungen abgeschlossen, teilen Sie die Ausgaben durch deren tatsächliche Anzahl.

Die Rechnung funktioniert für andere Aufgaben genauso. Bei Verbrauchsabrechnung multiplizieren Sie die abrechenbaren Anfragen mit dem Tarifpreis und berücksichtigen, für wie viele Anfragen dieser gilt. Bei einem Paket verwenden Sie den vollen Kaufpreis. Teilen Sie die Ausgaben anschließend durch die abgeschlossenen Aufgaben. Nutzen mehrere Projekte ein Paket, legen Sie die Kostenverteilung fest.

Prüfen Sie auch, ob die Anwendung rechtzeitig fertig wird. Das Beispiel verlangt 7.200 Prüfungen pro Tag, im Mittel fünf Starts pro Minute. Sie könnten alle 150 Prüfungen jede halbe Stunde gleichzeitig starten oder über das Intervall verteilen. Bei der angenommenen Versuchszahl bleibt der Paketverbrauch gleich, die Startlast unterscheidet sich jedoch. Ein Verbindungs- oder Anfrageratenlimit kann den ersten Zeitplan verhindern.

Unnötige Anfragen reduzieren

Entfernen Sie doppelte Adressen und speichern Sie Ergebnisse während der Arbeit. Nach einem Fehler sollte die Anwendung am Unterbrechungspunkt fortsetzen. Startet sie jedes Mal die ganze Liste neu, verbrauchen bereits bearbeitete Seiten erneut Kontingent. Halten Sie fest, welche Aufgaben abgeschlossen und welche noch offen sind.

Nutzen Sie die für die Daten benötigte Lademethode. Steht der gesuchte Text bereits in der Serverantwort, ist ein Browser möglicherweise unnötig. Erscheinen Daten erst nach Skriptausführung, reicht ein einfacher Download vielleicht nicht. Bei Datenerfassungsdiensten können Browsermodus und Zusatzfunktionen mehr Credits oder einen anderen Preis benötigen. Ein Credit entspricht daher nicht immer einer Anfrage.

Kleinere Antworten sparen nicht immer Anfragen. Zählt der Anbieter HTTP-Aufrufe, kann eine kurze Antwort genauso viele Anfragen verbrauchen wie eine lange. Sie können die Anzahl senken, indem Sie unveränderte Daten seltener prüfen, gespeicherte Ergebnisse verwenden oder mehrere Datensätze mit einem API-Aufruf abrufen. Die Informationen müssen für die Aufgabe ausreichend aktuell bleiben.

Begrenzen Sie Wiederholungen und beachten Sie den Fehlergrund. Ist eine Website vorübergehend unerreichbar oder verlangt eine geringere Rate, kann eine sofortige Wiederholung dieselbe Antwort liefern und eine weitere Anfrage verbrauchen. Eine Pause oder geringere Häufigkeit kann nützlicher sein. Seien Sie bei Aktionen mit neuen oder geänderten Daten besonders vorsichtig: Prüfen Sie vor erneutem Senden das Ergebnis des ersten Versuchs. Eine verlorene Antwort bedeutet nicht, dass der Server nichts getan hat.

Prüfen Sie nach Änderungen Ergebnisse und Verbrauch. Die Anfragezahl kann sinken, weil die Anwendung einen Teil der Aufgabe nicht mehr erledigt. Eine Reduktion ist sinnvoll, wenn die erforderlichen Daten mit gleicher Vollständigkeit und Aktualität durch weniger Anfragen erhalten werden.

Worauf Sie bei der Tarifwahl achten sollten

Klären Sie zuerst, ob der Dienst mit Ihren Websites und Ihrer Anwendung funktioniert. Proxytyp, verfügbare Länder, Sitzungsverhalten und der Zugriff auf benötigte Seiten über die bereitgestellten IPs sind wichtig. Vergleichen Sie anschließend die enthaltene Arbeit: Wer lädt die Seite, betreibt den Browser, extrahiert Daten und wiederholt fehlgeschlagene Versuche? Das erklärt unterschiedliche Anfragepreise.

Prüfen Sie Paketgültigkeit, Nachkaufregeln und den Umgang mit ungenutzten Anfragen. Ein großes Paket mit geringerem Anfragepreis lohnt sich, wenn Sie es rechtzeitig für benötigte Arbeit nutzen können. Bleiben gekaufte Anfragen ungenutzt, können die Kosten pro abgeschlossener Aufgabe höher sein als bei einem kleineren Paket.

Wählen Sie für einen Vergleich typische Projektseiten einschließlich gewöhnlich schwieriger Fälle. Erfassen Sie Dauer, verbrauchte Anfragen, erhaltene Ergebnisse und Anwendungseinstellungen. Dieser Test zeigt die benötigte Paketgröße, ungefähre Kosten und die zeitliche Machbarkeit.