autocannon: Node.js HTTP Lasttest (Schritt-für-Schritt Anleitung)

HTTP-Endpunkte mit Autocannon lasttesten, dem Node.js-Benchmarking-Tool. Installieren, mit -c/-d/-p ausführen, Latenz-Perzentile ablesen und in CI skripten.

Ashley Innocent

Ashley Innocent

6 July 2026

autocannon: Node.js HTTP Lasttest (Schritt-für-Schritt Anleitung)

Apidog für Unternehmen

On-Premises Bereitstellung

SSO & RBAC

SOC 2 konform

Apidog Enterprise entdecken

Sie haben einen HTTP-Endpunkt geschrieben. Er funktioniert, wenn Sie ihn einmal über Postman aufrufen. Aber was passiert, wenn 200 Clients ihn gleichzeitig aufrufen? Sie brauchen Zahlen: Anfragen pro Sekunde, Latenz-Perzentile und wie viele Antworten mit einem Status ungleich 2xx zurückkamen. autocannon liefert Ihnen diese Zahlen in etwa zehn Sekunden direkt in Ihrem Terminal.

autocannon ist ein HTTP/1.1-Benchmarking-Tool, das in Node.js geschrieben wurde. Es sendet eine kontrollierte Flut von Anfragen an eine URL und berichtet über Durchsatz und Latenz. Dieser Leitfaden führt Sie durch die Installation, einen grundlegenden Ablauf, alle Flags, die Sie tatsächlich verwenden werden, das Lesen der Ausgabe und die Steuerung von autocannon aus einem Node-Skript. Er zieht auch eine klare Grenze zwischen dem, was ein Lasttest Ihnen sagt und was nicht, damit Sie wissen, wann stattdessen ein funktionaler und Kontrakttest erforderlich ist.

button

Was autocannon ist

autocannon öffnet eine feste Anzahl gleichzeitiger Verbindungen zu einer URL und sendet für eine festgelegte Dauer (oder eine festgelegte Anzahl von Anfragen) weiterhin Anfragen. Währenddessen misst es die Latenz und zählt die Antworten. Wenn es fertig ist, druckt es eine Tabelle mit Latenz-Perzentilen und eine Zusammenfassung der Gesamtanfragen und gelesenen Bytes.

Es misst eine Sache: wie viel Last Ihr Server bewältigt und wie schnell er unter dieser Last reagiert. Es überprüft nicht, ob der Antworttext korrekt ist, ob Ihre API mit ihrer OpenAPI-Spezifikation übereinstimmt oder ob ein mehrstufiger Workflow bei jedem Schritt die richtigen Daten zurückgibt. Beachten Sie diesen Unterschied. Er prägt, wo autocannon in Ihren Test-Stack passt, was am Ende behandelt wird.

Wenn Sie wrk oder Apache Bench verwendet haben, füllt autocannon die gleiche Lücke mit einer Node-nativen Installation und einer programmatischen API, die Sie aus JavaScript aufrufen können.

Installation

autocannon wird als npm-Paket ausgeliefert. Installieren Sie es global, um den Befehl autocannon überall verfügbar zu haben:

npm i autocannon -g

Sie benötigen zuerst Node.js. Wenn Sie es lieber nicht global installieren möchten, führen Sie es bei Bedarf mit npx aus:

npx autocannon http://localhost:3000

Oder fügen Sie es als Entwicklungsabhängigkeit zu einem Projekt hinzu, wenn Sie es skripten möchten:

npm i autocannon --save-dev

Überprüfen Sie die Installation:

autocannon --version

Grundlegender Ablauf

Die einfachste Form ist der Befehl plus eine URL. Dies führt den Standard-Benchmark aus: 10 Verbindungen für 10 Sekunden.

autocannon http://localhost:3000

Steuern Sie die Parameter mit drei Flags, die Sie ständig verwenden werden. -c legt die Anzahl der gleichzeitigen Verbindungen fest, -d legt die Dauer in Sekunden fest und -p legt das Pipelining fest (wie viele Anfragen jede Verbindung sendet, bevor sie auf eine Antwort wartet).

autocannon -c 100 -d 30 -p 10 http://localhost:3000

Dieser Befehl öffnet 100 Verbindungen, läuft 30 Sekunden lang und pipelined 10 Anfragen pro Verbindung. Höhere Verbindungs- und Pipelining-Anzahlen erzeugen mehr Last, wodurch Sie den Punkt finden, an dem die Latenz zu steigen beginnt.

Um eine feste Anzahl von Anfragen anstatt einer bestimmten Dauer zu senden, verwenden Sie -a (amount):

autocannon -c 10 -a 10000 http://localhost:3000

Das stoppt nach 10.000 Anfragen, unabhängig von der Zeit.

POST-Anfragen, Header und ein Body

Ändern Sie die Methode mit -m, fügen Sie Header mit -H hinzu und übergeben Sie einen Anfrage-Body mit -b. Hier ist ein POST an einen JSON-Endpunkt:

autocannon -c 50 -d 20 \
  -m POST \
  -H 'Content-Type=application/json' \
  -H 'Authorization=Bearer YOUR_TOKEN' \
  -b '{"name":"load-test","active":true}' \
  http://localhost:3000/api/users

Beachten Sie das Header-Format: -H 'Key=Value', und Sie wiederholen -H für jeden Header. Wenn Ihr Body groß ist oder in einer Datei liegt, verwenden Sie -i, um ihn von der Festplatte zu lesen, anstatt ihn inline einzufügen:

autocannon -m POST -H 'Content-Type=application/json' -i payload.json http://localhost:3000/api/users

Begrenzung der Testrate

Standardmäßig sendet autocannon so schnell wie möglich. Manchmal möchten Sie eine konstante, realistische Rate anstatt einer maximalen Druckflut. -R begrenzt die Gesamtzahl der Anfragen pro Sekunde über alle Verbindungen hinweg:

autocannon -c 50 -R 500 -d 60 http://localhost:3000

Das hält den Test 60 Sekunden lang bei 500 Anfragen pro Sekunde. Dies ist nützlich, wenn Sie die Latenz bei einer erwarteten Produktionslast messen möchten, anstatt am Bruchpunkt.

Aufwärmen und Worker-Threads

Zwei weitere Flags helfen bei intensiveren Läufen. -W (Warmup) sendet für ein kurzes Intervall Traffic, bevor autocannon mit dem Sampling beginnt, damit Ihre ersten Zahlen nicht durch kalte Caches oder einen JIT, der sich noch nicht aufgewärmt hat, verfälscht werden. -w (Workers) verteilt die Last auf mehrere Node-Worker-Threads, was wichtig ist, wenn ein einzelner Thread nicht genügend Anfragen generieren kann, um einen schnellen Server zu sättigen:

autocannon -c 200 -d 30 -w 4 http://localhost:3000

Verwenden Sie -w nur, wenn Sie bestätigt haben, dass der Lastgenerator selbst der Engpass ist. Wenn die Latenz verdächtig flach aussieht, während Sie -c erhöhen, könnte Ihr Generator am Limit sein, und das Hinzufügen von Workern gibt Ihnen ein wahreres Bild der Servergrenze.

Die Ergebnisse lesen

Wenn ein Lauf beendet ist, druckt autocannon eine Latenztabelle und eine Zusammenfassungszeile. Ein gekürztes Beispiel:

Running 10s test @ http://localhost:3000
10 connections

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬──────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max      │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼──────────┤
│ Latency │ 0 ms │ 1 ms │ 4 ms  │ 6 ms │ 1.2 ms  │ 0.9 ms  │ 24.1 ms  │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴──────────┘

251k requests in 10.05s, 27.9 MB read

So lesen Sie es:

Zwei Flags machen die Ausgabe nützlicher. Fügen Sie -l hinzu, um den vollständigen Satz von Latenz-Perzentilen (einschließlich p99.9 und darüber hinaus) anzuzeigen, und fügen Sie --renderStatusCodes hinzu, um eine Aufschlüsselung nach Statuscodes zu sehen, damit Sie eine Welle von 500er-Fehlern erkennen können, die sich hinter einer guten Durchsatznummer verstecken:

autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000

Achten Sie auf Fehler, Timeouts und Nicht-2xx-Zählungen. Ein Server kann eine hohe Anfragerate aufweisen, während er stillschweigend Fehler zurückgibt. Wenn Nicht-2xx nicht Null ist, misst Ihre Durchsatznummer Misserfolge, nicht Erfolge.

Programmatische Verwendung in einem Skript

autocannon stellt eine Node.js-API bereit, sodass Sie Benchmarks aus einem Skript ausführen und auf die Ergebnisse reagieren können. Hier erweist es sich bei der Automatisierung als nützlich: Führen Sie einen Test durch, lesen Sie die Zahlen und lassen Sie einen Build fehlschlagen, wenn die Latenz einen Schwellenwert überschreitet.

Der Kernaufruf akzeptiert ein Options-Objekt und gibt ein Promise zurück:

const autocannon = require('autocannon')

async function run() {
  const result = await autocannon({
    url: 'http://localhost:3000',
    connections: 100,
    duration: 20,
    pipelining: 1
  })

  console.log(`Avg latency: ${result.latency.average} ms`)
  console.log(`Req/sec: ${result.requests.average}`)
  console.log(`Non-2xx: ${result.non2xx}`)
}

run()

Das result-Objekt enthält Histogramme für latency, requests und throughput, jedes mit Feldern wie average, min, max und Perzentilfeldern wie p99. Es enthält auch errors, timeouts und non2xx-Zählungen.

Um dies in ein Gate zu verwandeln, fügen Sie eine Überprüfung hinzu, die mit einem Wert ungleich Null beendet wird, wenn ein Budget überschritten wird:

const autocannon = require('autocannon')

const P99_BUDGET_MS = 250

async function run() {
  const result = await autocannon({
    url: 'http://localhost:3000/api/health',
    connections: 100,
    duration: 30
  })

  const p99 = result.latency.p99
  console.log(`p99 latency: ${p99} ms (budget ${P99_BUDGET_MS} ms)`)

  if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
    console.error('Performance budget exceeded')
    process.exit(1)
  }
}

run()

Wenn Sie den Live-Fortschrittsbalken und die Ergebnistabelle der CLI sehen möchten, übergeben Sie die Instanz an autocannon.track:

const autocannon = require('autocannon')

const instance = autocannon({
  url: 'http://localhost:3000',
  connections: 10,
  duration: 10
}, console.log)

autocannon.track(instance, { renderProgressBar: true })

process.once('SIGINT', () => instance.stop())

Für ein Szenario mit mehreren Anfragen übergeben Sie ein requests-Array, sodass jede Verbindung mehrere Aufrufe durchläuft:

autocannon({
  url: 'http://localhost:3000',
  connections: 20,
  duration: 15,
  requests: [
    { method: 'GET', path: '/api/users' },
    { method: 'POST', path: '/api/data', body: '{"x":1}',
      headers: { 'Content-Type': 'application/json' } }
  ]
}, console.log)

autocannon vs. wrk und ab

Alle drei beantworten die gleiche Frage (wie schnell, unter welcher Last), und die richtige Wahl hängt von Ihrem Stack ab.

Wenn Node Ihre Laufzeitumgebung ist, ist autocannon die reibungsarme Wahl. Bevorzugen Sie Python-Tools? Sehen Sie, wie man Lasttests ohne Python durchführt. Möchten Sie eine skriptfähige Option mit einem großen Funktionsumfang? Vergleichen Sie k6 Lasttests.

Wo Funktionstests und Apidog passen

autocannon sagt Ihnen, dass Ihr Endpunkt 12.000 Anfragen pro Sekunde bei einem p99 von 40 ms verarbeitet. Es sagt Ihnen nicht, ob der Endpunkt die richtigen Daten zurückgibt. Ein Lasttest kann mit Bravour bestehen, während die API fehlerhaftes JSON zurückgibt, einen Auth-Header ignoriert oder von ihrem OpenAPI-Vertrag abweicht. Durchsatz ist nicht Korrektheit.

Das ist die Lücke, die Funktionstests und Kontrakttests füllen, und hier ergänzt Apidog ein Lasttool, anstatt es zu ersetzen. Apidog ist kein Lastgenerator. Es führt gespeicherte Testszenarien aus, die Statuscodes, Antwortschemata und Werte über mehrstufige Abläufe hinweg überprüfen, sodass Sie Fehler erkennen können, die ein Benchmark nicht sehen kann.

Sie führen beides in CI aus, und sie beantworten unterschiedliche Fragen. Verwenden Sie autocannon (oder wrk), um die Frage „Ist es unter Last schnell genug?“ zu beantworten. Verwenden Sie die Apidog CLI, um die Frage „Ist es korrekt?“ zu beantworten. Die Apidog CLI ist headless und führt gespeicherte Testszenarien oder Suiten von jedem CI-Schritt aus, der Node unterstützt:

npm install -g apidog-cli

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioOrSuiteId> \
  -e <environmentId> \
  -r cli,html,junit

Das Flag -t zielt auf ein gespeichertes Szenario, einen Ordner oder eine Suite nach ID ab, -e wählt die Umgebung aus und -r wählt einen oder mehrere Reporter (cli, html, json, junit) aus, sodass der Lauf Artefakte erzeugt, die Ihre Pipeline archivieren kann. Für eine vollständige Anleitung siehe wie man API-Tests von der Apidog CLI ausführt, die Copy-Paste CI/CD-Pipeline und den GitHub Actions Workflow.

Eine gesunde Pipeline führt bei jedem Push Funktions- und Vertragsprüfungen durch (funktioniert es?), dann einen Lasttest vor der Veröffentlichung (hält es stand?). autocannon beantwortet die zweite Frage. Apidog beantwortet die erste.

FAQ

Ist autocannon für Lasttests in der Produktion genau?

autocannon liefert zuverlässige Durchsatz- und Latenzwerte für HTTP/1.1-Endpunkte, und wenn Sie eine Zielrate mit -R festlegen, korrigiert es die koordinierte Auslassung, einen Schritt, den viele einfachere Tools überspringen. Für genaue Ergebnisse führen Sie es von einem Rechner aus, der sich in der Nähe Ihres Servers befindet (andernfalls dominiert die Netzwerklatenz), und verwenden Sie genügend Verbindungen, um den Endpunkt zu sättigen. Führen Sie es gegen eine Staging-Umgebung aus, die die Produktion widerspiegelt, nicht gegen den Entwicklungs-Server Ihres Laptops.

Unterstützt autocannon HTTP/2 oder WebSockets?

Nein. autocannon benchmarkt HTTP/1.1. Für HTTP/2- oder WebSocket-Lasttests benötigen Sie ein anderes Tool. Dies ist die Haupteinschränkung, die Sie vor der Auswahl prüfen sollten.

Wie viele Verbindungen sollte ich verwenden?

Beginnen Sie mit dem Standardwert von 10, dann erhöhen Sie -c, bis die Anfragen pro Sekunde nicht mehr steigen und die Latenz zu klettern beginnt. Dieser Wendepunkt ist ungefähr die Kapazität Ihres Servers. Wenn Sie weit darüber hinausgehen, messen Sie eher die Grenzen Ihres Lastgenerators als die Ihres Servers.

Kann ich autocannon in CI ausführen?

Ja. Die programmatische API ist dafür ausgelegt: Führen Sie einen Benchmark aus, lesen Sie result.latency.p99 und result.non2xx und rufen Sie process.exit(1) auf, wenn ein Budget überschritten wird. Das verwandelt einen Benchmark in ein Pass/Fail-Gate, das Sie in jeden Node-fähigen CI-Schritt integrieren können.

Was ist der Unterschied zwischen -a und -d?

-d läuft für eine bestimmte Anzahl von Sekunden. -a läuft, bis eine bestimmte Anzahl von Anfragen abgeschlossen ist, und stoppt dann. Verwenden Sie -d für einen Lasttest im stabilen Zustand und -a, wenn Sie eine genaue Anzahl von Anfragen senden möchten.

Praktizieren Sie API Design-First in Apidog

Entdecken Sie eine einfachere Möglichkeit, APIs zu erstellen und zu nutzen