การทดสอบโหลด API ด้วย Artillery: คู่มือเชิงปฏิบัติ

Artillery คือชุดเครื่องมือโอเพนซอร์สสำหรับทดสอบโหลด Node.js ที่สร้างปริมาณการใช้งานแบบพร้อมกันสูง (high-concurrency traffic) ไปยัง API ของคุณจากสคริปต์ YAML ง่ายๆ คุณกำหนดเฟสการโหลดและโฟลว์คำขอ รัน `artillery run script.yml` และอ่านค่าเปอร์เซ็นไทล์ของความหน่วง (latency percentiles), อัตราคำขอ และจำนวนข้อผิดพลาด คู่มือนี้จะแนะนำคุณเกี่ยวกับการติดตั้ง Artillery v2 การเขียนสคริปต์ทดสอบจริง การรัน การเก็บผลลัพธ์ด้วยวิธีการของ v2 ปัจจุบัน และการเชื่อมต่อเข้ากับ CI

Artillery คืออะไร และเมื่อใดที่คุณควรใช้มัน

Artillery สร้างผู้ใช้เสมือน (VUs) ที่ส่งคำขอไปยังปลายทาง (endpoints) ของคุณ และวัดว่าระบบรองรับปริมาณการใช้งานที่ต่อเนื่องได้อย่างไร ผู้ใช้เสมือนคือไคลเอนต์จำลองที่รันผ่านสถานการณ์จำลอง ทีละคำขอ เหมือนกับผู้เรียกใช้งานจริง

คุณควรใช้ Artillery เมื่อคุณต้องการคำตอบสำหรับคำถามด้านการปรับขนาด (scale) เช่น ความหน่วง p95 ทำงานอย่างไรเมื่อมีคำขอ 50 ครั้งต่อวินาที? อัตราการเข้าถึง (arrival rate) เท่าใดที่ข้อผิดพลาดเริ่มปรากฏขึ้น? API ยังคงเสถียรเป็นเวลาห้านาทีภายใต้โหลดที่ต่อเนื่อง หรือประสิทธิภาพลดลง?

Artillery เหมาะสำหรับงานนี้เนื่องจากการทดสอบเป็นแบบประกาศ (declarative) คุณอธิบายรูปแบบการโหลดใน YAML แทนที่จะต้องเขียนโค้ดลูปสำหรับการทำงานพร้อมกันด้วยมือ มันทำงานได้ทุกที่ที่ Node.js ทำงานได้ ดังนั้นสคริปต์เดียวกันนี้สามารถใช้ได้ทั้งบนแล็ปท็อปของคุณและใน CI

Artillery เป็นหนึ่งในหลายทางเลือกในสาขานี้ หากคุณยังคงเปรียบเทียบเครื่องมือต่างๆ บทสรุปเครื่องมือทดสอบโหลดชั้นนำ และ การเปรียบเทียบซอฟต์แวร์ทดสอบโหลด นี้ครอบคลุมข้อดีข้อเสียของ k6, JMeter, Gatling และอื่นๆ

ติดตั้ง Artillery (v2)

ชื่อแพ็คเกจคือ `artillery` และเวอร์ชันหลักปัจจุบันคือ v2 ติดตั้งแบบ global ด้วย npm จากนั้นตรวจสอบเวอร์ชัน

npm install -g artillery@latest
artillery version

คุณต้องใช้ Node.js เวอร์ชัน LTS ล่าสุด Artillery ทำงานได้บน Windows, macOS และ Linux

หากคุณไม่ต้องการติดตั้งอะไรแบบ global สามารถรันตามต้องการด้วย `npx`

npx artillery@latest run script.yml

การเขียนสคริปต์ทดสอบ Artillery

การทดสอบ Artillery คือไฟล์ YAML ที่มีสองส่วนหลัก ส่วน `config` กำหนดเป้าหมาย (target) และโปรไฟล์การโหลด ส่วน `scenarios` กำหนดว่าผู้ใช้เสมือนแต่ละคนทำอะไร

นี่คือสคริปต์ที่สมบูรณ์ที่วอร์มอัพ (เตรียมความพร้อม) เพิ่มขึ้นจนถึงจุดสูงสุด และคงโหลดไว้

config:
  target: "https://api.example.com"
  phases:
    - name: "Warm up"
      duration: 60
      arrivalRate: 5
    - name: "Ramp to peak"
      duration: 120
      arrivalRate: 5
      rampTo: 50
    - name: "Sustained load"
      duration: 300
      arrivalRate: 50
      maxVusers: 500
  # Inline variables (or use a CSV via config.payload)
  variables:
    productId:
      - "1001"
      - "1002"

scenarios:
  - name: "Browse and create order"
    flow:
      - get:
          url: "/v1/products/{{ productId }}"
      - post:
          url: "/v1/orders"
          json:
            productId: "{{ productId }}"
            quantity: 2

ทำความเข้าใจส่วน config

`config.target` คือโฮสต์หลักที่ทุกคำขอจะถูกส่งไป แต่ละขั้นตอนในสถานการณ์จำลองจะเพิ่ม `url` ของตัวเองต่อท้ายฐานนี้

`config.phases` คืออาร์เรย์ของเฟสการโหลดที่จะรันตามลำดับ คีย์ที่คุณจะใช้บ่อยที่สุด:

• `duration`: ระยะเวลาที่เฟสนี้คงอยู่เป็นวินาที หรือสตริงที่อ่านง่าย เช่น `"5m"`
• `arrivalRate`: จำนวนผู้ใช้เสมือนใหม่ที่เริ่มในแต่ละวินาที
• `rampTo`: เพิ่มอัตราการเข้าถึง (arrival rate) แบบเชิงเส้นจาก `arrivalRate` ไปยังค่านี้ตลอดทั้งเฟส
• `arrivalCount`: จำนวน VUs ที่กำหนดซึ่งกระจายตลอดทั้งเฟส แทนที่จะเป็นอัตราต่อวินาที
• `maxVusers`: จำนวนสูงสุดของผู้ใช้เสมือนที่สามารถรันพร้อมกันได้
• `name`: ป้ายกำกับที่จะแสดงในผลลัพธ์

มีรายละเอียดหนึ่งที่มักทำให้คนสับสน `duration` ของเฟสจะควบคุมระยะเวลาที่ Artillery สร้างผู้ใช้เสมือน ไม่ใช่เวลาจริงทั้งหมดของการทดสอบ หาก VU เริ่มต้นใกล้สิ้นสุดเฟสและสถานการณ์จำลองใช้เวลานาน การรันจะดำเนินต่อไปจนกว่าผู้ใช้นั้นจะเสร็จสิ้น

ทำความเข้าใจส่วน scenarios

`scenarios` คืออาร์เรย์ แต่ละสถานการณ์จำลองมี `flow` ซึ่งเป็นรายการขั้นตอนที่จัดลำดับซึ่งผู้ใช้เสมือนจะรัน คีย์เสริมได้แก่ `name` และ `weight` โดยที่ `weight` กำหนดความน่าจะเป็นสัมพัทธ์ที่ Artillery จะเลือกสถานการณ์จำลองนี้สำหรับ VU ที่กำหนด

ขั้นตอนของโฟลว์ใช้คีย์คำกริยา HTTP: `get`, `post`, `put`, `delete` และ `patch` แต่ละรายการรับ `url` และเนื้อหาคำขอจะอยู่ภายใต้ `json` ไวยากรณ์วงเล็บปีกกาคู่ `{{ productId }}` ดึงตัวแปรเข้ามา

การขับเคลื่อนคำขอจากไฟล์ CSV

การกำหนดค่าด้วยโค้ดโดยตรง (Hard-coding) ใช้ได้สำหรับการทดสอบแบบ smoke test สำหรับการโหลดที่สมจริง ให้ป้อนข้อมูลจาก CSV ด้วย `config.payload` ผู้ใช้เสมือนแต่ละคนจะเลือกแถวหนึ่ง และชื่อคอลัมน์จะกลายเป็นตัวแปร

config:
  target: "https://api.example.com"
  payload:
    path: "./users.csv"
    fields:
      - "email"
      - "password"
  phases:
    - duration: 120
      arrivalRate: 20
scenarios:
  - flow:
      - post:
          url: "/login"
          json:
            email: "{{ email }}"
            password: "{{ password }}"

การรันการทดสอบ

คำสั่งพื้นฐานที่ Artillery ใช้กับสคริปต์ของคุณ

artillery run script.yml

# Override target without editing the script:
artillery run --target https://staging.example.com script.yml

# Pass variables as JSON:
artillery run -v '{ "productId": ["1001","1002"] }' script.yml

มีแฟล็กบางตัวที่ควรรู้ `--target` (หรือ `-t`) จะแทนที่ `config.target` เพื่อให้คุณสามารถชี้สคริปต์เดียวกันไปยังสภาพแวดล้อม staging หรือ production ได้ `--environment` (หรือ `-e`) เลือกบล็อกที่มีชื่อภายใต้ `config.environments` `--config` (หรือ `-c`) โหลด config จากไฟล์แยกต่างหาก `--insecure` (หรือ `-k`) ข้ามการตรวจสอบ TLS สำหรับใบรับรองแบบ self-signed ในสภาพแวดล้อมการทดสอบ

การอ่านผลลัพธ์

ขณะที่การทดสอบกำลังทำงาน Artillery จะแสดงเมตริกรวมประมาณทุก 10 วินาที เมื่อเสร็จสิ้น คุณจะได้รับรายงานสรุป ตัวเลขที่สำคัญที่สุด:

• อัตราคำขอ: จำนวนคำขอต่อวินาทีที่การรันทำได้จริง
• เปอร์เซ็นไทล์ของความหน่วง: เวลาตอบสนอง p50 (มัธยฐาน), p95 และ p99 p95 บอกคุณถึงประสบการณ์ของคำขอที่ช้าที่สุด 5 เปอร์เซ็นต์ ซึ่งโดยปกติแล้วจะเป็นจุดที่ปัญหาปรากฏขึ้นก่อน
• จำนวนข้อผิดพลาด: คำขอที่ล้มเหลว, การหมดเวลา (timeouts) และการตอบกลับที่ไม่ใช่ 2xx จัดกลุ่มตามประเภท

สังเกตความหน่วงที่ส่วนท้าย (tail latencies) ไม่ใช่แค่ค่าเฉลี่ย ค่าเฉลี่ยอาจดูปกติในขณะที่ p99 ค่อยๆ เพิ่มขึ้นเป็นหลายวินาที หากข้อผิดพลาดปรากฏเฉพาะในช่วงเฟสที่คงที่ คุณอาจพบจุดอิ่มตัวที่ควรตรวจสอบ สำหรับการเจาะลึกเพิ่มเติมว่าควรติดตามเมตริกใดและเหตุผลใด โปรดดู คู่มือการทดสอบประสิทธิภาพ API นี้

การสร้างรายงานใน Artillery v2

การสร้างรายงานมีการเปลี่ยนแปลงในแต่ละเวอร์ชันของ Artillery นี่คือจุดที่บทเรียนเก่าๆ อาจทำให้คุณเข้าใจผิด คู่มือเก่าๆ จะบอกให้คุณรัน `artillery run --output report.json` แล้วตามด้วย `artillery report report.json` เพื่อสร้างไฟล์ HTML ส่วนแรกยังคงใช้ได้ แต่ส่วนที่สองไม่ใช้ไม่ได้แล้ว

แฟล็ก `--output` ยังคงเขียนไฟล์ผลลัพธ์ JSON ที่เครื่องอ่านได้

# Write machine-readable JSON results (still supported):
artillery run --output report.json script.yml

คำสั่ง `artillery report` ซึ่งเป็นตัวสร้าง JSON เป็น HTML ได้ถูกนำออกจาก Artillery CLI แล้ว เอกสารทางการระบุว่า "ไม่ได้รับการสนับสนุนอีกต่อไปและถูกนำออกจาก Artillery CLI แล้ว" โค้ดสำหรับรายงาน HTML ไม่ได้รับการดูแล ถูกเลิกใช้งาน และถูกตัดออกไป โดยไม่มีแผนที่จะนำกลับมาใช้ใหม่ อย่าใช้ `artillery report report.json`; มันจะไม่ทำงานกับ v2 ปัจจุบัน

มีสามทางเลือกในปัจจุบันแทน

ประการแรก, แยกวิเคราะห์ JSON ด้วยตัวคุณเอง วิธีนี้เหมาะสำหรับ CI ซึ่งคุณต้องการยืนยันเทียบกับเกณฑ์ ดึงค่าความหน่วง p95 รวมด้วย `jq`:

jq '.aggregate.summaries["http.response_time"].p95' report.json

ประการที่สอง, ใช้ Artillery Cloud สำหรับแดชบอร์ดที่โฮสต์ นี่คือการแทนที่อย่างเป็นทางการสำหรับรายงาน HTML แบบเก่า ส่ง `--record` พร้อมกับคีย์ API ของคุณ

artillery run --record --key $ARTILLERY_CLOUD_API_KEY script.yml

ประการที่สาม, ผลักเมตริกไปยังระบบมอนิเตอร์ของคุณด้วยปลั๊กอิน `publish-metrics` หรือ OpenTelemetry เพื่อให้ความหน่วงและอัตราข้อผิดพลาดแสดงในแดชบอร์ดเดียวกับที่คุณใช้สำหรับการผลิตอยู่แล้ว

การรัน Artillery ใน CI

เนื่องจาก Artillery เป็นเพียง CLI ของ Node.js จึงสามารถนำไปใช้ใน pipeline ใดก็ได้ นี่คือเวิร์กโฟลว์ GitHub Actions ที่ติดตั้ง Artillery รันการทดสอบ และอัปโหลดรายงาน JSON เป็น build artifact

name: Load test
on: [workflow_dispatch]
jobs:
  artillery:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
      - run: npm install -g artillery@latest
      - run: artillery run --output report.json script.yml
      - uses: actions/upload-artifact@v4
        with:
          name: artillery-report
          path: report.json

ตัวอย่างนี้รันด้วยการสั่งงานด้วยตนเอง การทดสอบโหลดหนักมักจะถูกสั่งงานตามความต้องการหรือตามกำหนดเวลา แทนที่จะรันทุกครั้งที่มีการ commit เนื่องจากใช้เวลาหลายนาทีและใช้แบนด์วิดท์จริง เมื่อมีรายงาน JSON แล้ว คุณสามารถเพิ่มขั้นตอน `jq` ที่จะทำให้งานล้มเหลวหาก p95 เกินงบประมาณของคุณ

Apidog เข้ามามีบทบาทอย่างไร: การทดสอบฟังก์ชันและการป้องกัน CI

Artillery ตอบคำถามว่า "API สามารถรองรับปริมาณการใช้งานนี้ได้หรือไม่" นั่นคือการทดสอบโหลดและประสิทธิภาพ คำถามที่แตกต่างกันที่มาพร้อมกันคือ "API ยังคงส่งคืนการตอบสนองที่ถูกต้องหลังจากเปลี่ยนโค้ดนี้หรือไม่" นั่นคือการทดสอบฟังก์ชันและการถดถอย และเป็นจุดที่ Apidog เข้ามามีบทบาท

Apidog เป็นแพลตฟอร์ม API แบบ All-in-one สำหรับการออกแบบ, การดีบัก, การจำลอง (mocking), เอกสาร และการทดสอบอัตโนมัติ สถานการณ์จำลองการทดสอบของมันจัดกลุ่มปลายทาง (endpoints) เป็นขั้นตอนเชิงตรรกะพร้อมเงื่อนไขเช่น if, for และ foreach เพื่อให้คุณสามารถตรวจสอบเนื้อหาการตอบกลับ, รหัสสถานะ และสัญญา คุณรันสถานการณ์จำลองเหล่านั้นใน CI ด้วย Apidog CLI เพื่อป้องกันการรวมโค้ดหลังจากการเปลี่ยนแปลง

ต้องเข้าใจถึงขอบเขต Apidog มีฟีเจอร์การทดสอบประสิทธิภาพ แต่จำกัดผู้ใช้เสมือนสูงสุด 100 คน ซึ่งเพียงพอที่จะตรวจจับการถดถอยที่ชัดเจน และไม่ใช่สิ่งทดแทน Artillery สำหรับการทำงานพร้อมกันสูง สำหรับการโหลดแบบกระจายที่จำลองด้วยโค้ดในระดับมหาศาล Artillery คือเครื่องมือที่เหมาะสม กรอบความคิดที่ซื่อสัตย์นี้ปรากฏอยู่ในบทความของเราเกี่ยวกับการ ทดสอบโหลด API โดยไม่ต้องใช้ Python และกลไกของฟีเจอร์ 100-VU ของ Apidog ถูกกล่าวถึงใน การทดสอบประสิทธิภาพ API ใน Apidog

ดังนั้นควรใช้ทั้งสองอย่าง ทดสอบโหลดด้วย Artillery สำหรับการปรับขนาด รันการตรวจสอบฟังก์ชันและการถดถอยใน CI ด้วย Apidog CLI เพื่อตรวจจับพฤติกรรมที่ผิดพลาดก่อนที่จะนำไปใช้งานจริง

Apidog CLI ติดตั้งจาก npm และ `apidog run` ใช้ได้เฉพาะแฟล็กเท่านั้น

# Apidog CLI: functional/regression run in CI (flag-only, no positional file)
npm install -g apidog-cli
apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t <TEST_SCENARIO_ID> \
  -e <ENVIRONMENT_ID> \
  -r cli,junit \
  --out-dir ./apidog-reports

แฟล็ก `-t` คือ ID สถานการณ์จำลองการทดสอบ `-e` คือ ID สภาพแวดล้อมที่จำเป็น และ `-r cli,junit` จะส่งออกทั้งเอาต์พุตคอนโซลและรายงาน JUnit XML ที่ระบบ CI สามารถอ่านได้ สำหรับคำแนะนำแบบทีละขั้นตอน โปรดดู บทเรียน Apidog CLI และสำหรับรูปแบบการออกแบบ pipeline โปรดดู แนวทางปฏิบัติที่ดีที่สุดของ CI/CD สำหรับการทดสอบ API เหล่านี้

ต้องการการทดสอบฟังก์ชันและสัญญาเพื่อป้องกัน CI ของคุณควบคู่ไปกับการรันโหลดของ Artillery หรือไม่? ดาวน์โหลด Apidog ฟรีและสร้างสถานการณ์จำลองการทดสอบแรกของคุณ

คำถามที่พบบ่อย

การทดสอบโหลดด้วย Artillery คืออะไร?

การทดสอบโหลดด้วย Artillery คือการใช้ชุดเครื่องมือโอเพนซอร์ส Artillery เพื่อจำลองผู้ใช้เสมือนจำนวนมากที่ส่งคำขอไปยัง API ของคุณพร้อมกัน คุณอธิบายรูปแบบการโหลดและโฟลว์คำขอในสคริปต์ YAML รันมัน และวัดเปอร์เซ็นไทล์ความหน่วง, อัตราคำขอ และข้อผิดพลาด เพื่อดูว่าระบบของคุณทำงานอย่างไรภายใต้ความกดดัน

Artillery ฟรีและเป็นโอเพนซอร์สหรือไม่?

ใช่ Artillery CLI หลักเป็นซอฟต์แวร์ฟรีและโอเพนซอร์ส แจกจ่ายบน npm ในชื่อแพ็คเกจ `artillery` นอกจากนี้ยังมีบริการแบบโฮสต์แบบเสียเงินคือ Artillery Cloud ซึ่งมีแดชบอร์ดสำหรับผลลัพธ์ แต่คุณสามารถรันการทดสอบโหลดแบบเต็มรูปแบบได้ทั้งในเครื่องและใน CI โดยไม่ต้องใช้มัน

คุณรันการทดสอบโหลดด้วย Artillery อย่างไร?

ติดตั้งด้วย `npm install -g artillery@latest` เขียนสคริปต์ YAML ที่มีบล็อก `config` (เป้าหมายและเฟส) และบล็อก `scenarios` (โฟลว์คำขอ) จากนั้นรัน `artillery run script.yml` Artillery จะแสดงเมตริกแบบเรียลไทม์ทุก 10 วินาทีและสรุปผลเมื่อสิ้นสุด

คุณสร้างรายงาน Artillery ได้อย่างไร?

รัน `artillery run --output report.json script.yml` เพื่อเขียนไฟล์ผลลัพธ์ JSON คำสั่ง `artillery report` แบบเก่าที่สร้าง HTML ถูกนำออกจาก CLI แล้ว ให้ใช้เครื่องมือเช่น `jq` เพื่อแยกวิเคราะห์ JSON แทน ใช้ Artillery Cloud ผ่าน `--record --key` หรือผลักเมตริกออกไปด้วยปลั๊กอิน publish-metrics หรือ OpenTelemetry

Artillery เทียบกับ k6 หรือ JMeter: คุณควรใช้อันไหนดี?

ทั้งสามตัวจัดการโหลดขนาดใหญ่ได้ Artillery ใช้ YAML แบบ declarative และ Node.js ซึ่งเหมาะกับทีมที่อยู่ในระบบนิเวศ JavaScript อยู่แล้ว k6 เขียนสคริปต์ด้วย JavaScript ในรูปแบบ code-first JMeter เป็นแบบ GUI-driven และใช้ Java โดยมีประวัติปลั๊กอินที่ยาวนาน การเปรียบเทียบ Gatling vs JMeter ครอบคลุมข้อดีข้อเสียอย่างละเอียด เลือกตัวที่โมเดลการเขียนสคริปต์เข้ากับทีมของคุณ จากนั้นจับคู่กับ CI tests เชิงฟังก์ชันเพื่อการครอบคลุมที่สมบูรณ์