הקמת תשתית בדיקות עומס JMeter

הקמת תשתית בדיקות עומס JMeter

תארו לעצמכם שאתם מריצים בדיקת עומס דרך JMeter, ואחרי 10 דקות ה-master קורס עם OutOfMemoryError. זו בעיה נפוצה—בדרך כלל האשמה היא בארכיטקטורה: מצב GUI במקום headless, תרחישים לא פרמטריים, או חוסר בעומס מבוזר. אנו מקימים תשתית turnkey—מביקורת של הבדיקות הנוכחיות שלכם ועד אינטגרציית CI/CD וניטור בזמן אמת. למהנדסים שלנו יש ניסיון של 10+ שנים בבדיקות עומס והם מחזיקים בהסמכות Kubernetes ו-DevOps (CKAD, AWS DevOps). עם הגדרה נכונה, אתם מקבלים תוצאות מדויקות וחוסכים עד 40% זמן בניתוח. צרו קשר לביקורת של הבדיקות שלכם—החל מ-$500—נעזור לפתור את הבעיה. להקמת תשתית מלאה, החבילות מתחילות ב-$2,000. בנוסף, הפחתת עלות תשתית אופיינית של 70% משמעותה שהקמה שעולה $1,000/חודש ב-VMs יכולה להיות מופחתת ל-$300 על spot instances, חיסכון של $700 בחודש.

טעויות נפוצות בהרצת JMeter: מצב GUI ו-GUI Listeners

GUI מיועד רק לפיתוח תרחישים וניפוי שגיאות. תמיד הריצו בדיקות עומס במצב CLI: jmeter -n -t test.jmx -l results.jtl. אחרת, אתם מסתכנים ב-OutOfMemoryError עם 50 משתמשים וירטואליים בלבד. בפרויקט אחד, הגדלנו את העומס המקסימלי מ-200 ל-10,000 תהליכונים מקבילים פשוט על ידי מעבר ל-headless והפצת slaves על פני 3 צמתי Kubernetes. ביצוע headless טוב פי 50 ממצב GUI מבחינת קיבולת משתמשים. ציטוט: JMeter Best Practices.

בעת איסוף תוצאות, ה-master גם סובל: אם GUI listeners (למשל View Results Tree) מופעלים בתרחיש, JMeter מאחסן כל עסקה בזיכרון. במצב headless, השביתו את כל GUI listeners, השאירו רק את Backend Listener ו-Simple Data Writer. זה מבטיח פעולה יציבה אפילו עם 10,000+ משתמשים מקבילים.

הקמת בדיקות JMeter מבוזרות ב-Kubernetes

JMeter תומך בעומס מבוזר מחוץ לקופסה. ה-master מנהל את הבדיקה, וה-slaves מייצרים את העומס. עבור תשתית CI/CD, הרצת JMeter slaves על Kubernetes נוחה יותר מאשר תחזוקת VMs ייעודיים. אנו משתמשים ב-Helm chart kubernauts/jmeter-k8s-starterkit. הגישה הבסיסית: Deployments עבור slaves, Job עבור ה-master.

---
# jmeter-slave-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: jmeter-slaves
  namespace: load-testing
spec:
  replicas: 3
  selector:
    matchLabels:
      app: jmeter-slave
  template:
    metadata:
      labels:
        app: jmeter-slave
    spec:
      containers:
        - name: jmeter
          image: justb4/jmeter:5.6.3
          command: ["/bin/sh", "-c"]
          args: ["jmeter-server -Djava.rmi.server.hostname=$(POD_IP)"]
          env:
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          ports:
            - containerPort: 1099
            - containerPort: 50000
          resources:
            requests:
              cpu: "2"
              memory: "2Gi"
            limits:
              cpu: "4"
              memory: "4Gi"
---
# jmeter-master-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: jmeter-master-{{ .Values.runId }}
spec:
  ttlSecondsAfterFinished: 7200
  template:
    spec:
      restartPolicy: Never
      initContainers:
        - name: wait-for-slaves
          image: busybox
          command: ['sh', '-c', 'until nc -z jmeter-slaves-svc 1099; do sleep 2; done']
      containers:
        - name: jmeter
          image: justb4/jmeter:5.6.3
          command: ["/bin/sh", "-c"]
          args:
            - jmeter
            - -n
            - -t
            - /tests/$(TEST_FILE)
            - -R
            - $(SLAVE_HOSTS)
            - -l
            - /results/results.jtl
            - -e
            - -o
            - /results/report/
            - -Jhost=$(TARGET_URL)
          volumeMounts:
            - name: tests
              mountPath: /tests
            - name: results
              mountPath: /results
---

VMs ייעודיים נותנים שליטה מלאה במשאבים והגדרת רשת קלה, אבל הם יקרים וקשים לסקילה. Kubernetes, לעומת זאת, מספק סקילה אלסטית ועלות נמוכה דרך spot instances, אבל דורש תשתית K8s קיימת וניפוי שגיאות רשת מורכב יותר. הסקילה של Kubernetes מהירה פי 3 מאשר VMs. השוואה:

אנו ממליצים על Kubernetes עבור סביבות דינמיות ו-CI/CD, ועל VMs עבור תצורות קבועות.

פרמטריזציה של תרחישים באמצעות Properties

כתובות URL מקודדות ב-# jmeter-slave-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: jmeter-slaves namespace: load-testing spec: replicas: 3 selector: matchLabels: app: jmeter-slave template: metadata: labels: app: jmeter-slave spec: containers: - name: jmeter image: justb4/jmeter:5.6.3 command: ["/bin/sh", "-c"] args: ["jmeter-server -Djava.rmi.server.hostname=$(POD_IP)"] env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP ports: - containerPort: 1099 - containerPort: 50000 resources: requests: cpu: "2" memory: "2Gi" limits: cpu: "4" memory: "4Gi" --- # jmeter-master-job.yaml apiVersion: batch/v1 kind: Job metadata: name: jmeter-master-{{ .Values.runId }} spec: ttlSecondsAfterFinished: 7200 template: spec: restartPolicy: Never initContainers: - name: wait-for-slaves image: busybox command: ['sh', '-c', 'until nc -z jmeter-slaves-svc 1099; do sleep 2; done'] containers: - name: jmeter image: justb4/jmeter:5.6.3 command: ["/bin/sh", "-c"] args: - jmeter -n -t /tests/$(TEST_FILE) -R $(SLAVE_HOSTS) -l /results/results.jtl -e -o /results/report/ -Jhost=$(TARGET_URL) volumeMounts: - name: tests mountPath: /tests - name: results mountPath: /results הן פרקטיקה רעה. פרמטריזציה באמצעות קבצי properties:

# test.properties host=staging.example.com port=443 protocol=https threads=100 rampup=60 duration=300 

jmeter -n -t test.jmx \ -q test.properties \ -Jthreads=200 \ # override конкретного параметра -l results.jtl 

ב-.jmx, משתנים משמשים כ-# test.properties host=staging.example.com port=443 protocol=https threads=100 rampup=60 duration=300 , jmeter -n -t test.jmx \ -q test.properties \ -Jthreads=200 \ # override конкретного параметра -l results.jtl . זה מאפשר לכתוב תרחיש אחד ולהריץ אותו מול סביבות שונות. חיסכון בזמן בבדיקות ידניות: עד 40%.

ניטור בדיקות בזמן אמת

JMeter כותב לקובץ .jmx לניתוח לאחר הבדיקה. לניטור בזמן אמת, השתמשו בתוסף Backend Listener. התקינו אותו דרך JMeter Plugin Manager. ראו תיעוד JMeter Backend Listener לפרטים.

<!-- Добавить в test.jmx -->
<BackendListener guiclass="BackendListenerGui" testclass="BackendListener" testname="InfluxDB Backend Listener">
  <elementProp name="arguments" elementType="Arguments">
    <collectionProp name="Arguments.arguments">
      <elementProp name="influxdbMetricsSender" elementType="Argument">
        <stringProp name="Argument.name">influxdbMetricsSender</stringProp>
        <stringProp name="Argument.value">org.apache.jmeter.visualizers.backend.influxdb.InfluxdbBackendListenerClient</stringProp>
      </elementProp>
      <elementProp name="influxdbUrl" elementType="Argument">
        <stringProp name="Argument.name">influxdbUrl</stringProp>
        <stringProp name="Argument.value">http://influxdb:8086/write?db=jmeter</stringProp>
      </elementProp>
      <elementProp name="application" elementType="Argument">
        <stringProp name="Argument.name">application</stringProp>
        <stringProp name="Argument.value">my-api</stringProp>
      </elementProp>
    </collectionProp>
  </elementProp>
</BackendListener>