كيفية اختبار أداء VPS بدقة باستخدام yabs.sh

ما المقصود باختبار أداء VPS

لاختبار أداء VPS، قِس أربعة أمور: سرعة تشغيل نواة CPU واحدة، وعرض نطاق الذاكرة في الجهاز، وعدد عمليات القرص العشوائية الصغيرة التي تنفذها وحدة التخزين كل ثانية، ومعدل النقل الذي يوفّره اتصال الشبكة. يمنحك تشغيل واحد للأداة yabs.sh هذه القياسات الأربعة في نحو عشر دقائق. لكن قراءة النتيجة هي الجزء الأصعب، لأن VPS يشارك العتاد الفعلي مع مستأجرين آخرين. لذلك قد يعرض الجهاز نفسه رقماً في الساعة 03:00 ورقماً مختلفاً كثيراً في الساعة 20:00.

تتمثل الخطة هنا في تشغيل yabs.sh للحصول على صورة سريعة، ثم تشغيل الأدوات التي تستخدمها هذه الأداة يدوياً. يتيح لك تشغيلها بنفسك تغيير خيار واحد، ومراقبة تغير الرقم، وفهم ما الذي كان هذا الرقم يقيسه فعلياً. نفّذ ذلك بعد إعداد الجهاز، وليس قبله. تسبق ذلك خطوات الدقائق العشر الأولى على VPS جديد، لأن جهازاً ما يزال يطبّق أول مجموعة من التحديثات يعطي نتائج اختبار أداء سيئة لأسباب لا علاقة لها بالعتاد.

افحص الآلة قبل أن تقيس أداءها

نصف كل اختبار أداء سيئ ينتج عن آلة لم يفهمها كاتب الاختبار.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM يعني المحاكاة الافتراضية الكاملة، ولذلك تشغّل نواة نظامك الخاصة. أما عرض systemd-detect-virt أو lxc أو openvz فيعني محاكاة افتراضية للحاويات بدلاً من ذلك: فأنت تشارك نواة المضيف، وتكون حدود CPU والذاكرة إعدادات cgroup (control group) بدلاً من عتاد افتراضي. في نظام يستخدم cgroup v2، يمكنك قراءة حد CPU مباشرة.

cat /sys/fs/cgroup/cpu.max

max 100000 يعني عدم وجود حصة. و200000 100000 يعني أنه يمكنك استخدام 200000 ميكروثانية من CPU في كل فترة مدتها 100000 ميكروثانية، أي ما يعادل حصة نواتين. لن يسجّل عرض يعلن عن 4 vCPU مع حصة تعادل نواتين نتيجة مماثلة لأربع نوى، ولن تطبع أي أداة لاختبار الأداء سطراً يوضح السبب.

df -hT / مهم لسبب مختلف: عمود Type. إذا كانت قيمته overlay، فأنت داخل حاوية، ويحتاج اختبار القرص أدناه إلى تعديل. دوّن ذلك الآن.

راقب وقت الاستيلاء طوال الفترة

وقت الاستيلاء هو النسبة من الوقت الذي كانت فيه وحدة المعالجة المركزية الافتراضية جاهزة للتشغيل، لكن برنامج hypervisor منح النواة الفعلية لجهة أخرى. وهو الإشارة المنفردة الأكثر فائدة لتحديد ما إذا كانت النتيجة ناتجة عن الأجهزة المجاورة لك، لا عن العتاد نفسه.

vmstat 1 10

اقرأ العمود st في الجهة اليمنى. تُعد القيمة الثابتة 0 أو 1 طبيعية. وتشير القيم المستمرة التي تتجاوز 5 إلى أن المضيف يعاني من فرط تخصيص الموارد في تلك اللحظة، ولذلك يكون كل رقم CPU تسجله خلال تلك الفترة منخفضاً من دون أن يكون جهازك هو السبب. يعرض top الرقم نفسه الذي يعرضه %st في سطر CPU. أبقِ vmstat 1 قيد التشغيل في جلسة SSH ثانية أثناء إجراء الاختبار، وسجّل قيمة الاستيلاء بجانب كل نتيجة.

ابدأ باستخدام yabs.sh

yabs.sh (اختصار Yet Another Bench Script) هو برنامج نصي لـshell ينزّل الملفات الثنائية الثابتة لـfio وiperf3 وGeekbench، ثم يشغّلها ويطبع ملخصاً واحداً. وهو اللغة المشتركة في نقاشات قياس أداء VPS، لذلك فإن مخرجات yabs هي أسرع طريقة لمقارنة النتائج مع شخص آخر.

الصيغة ذات السطر الواحد التي يوفّرها المشروع هي التالية.

curl -sL yabs.sh | bash

يرسل هذا الأمر كل ما يقدّمه عنوان URL حالياً مباشرةً إلى shell. نزّل الملف واقرأه، ثم شغّله.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

تأتي الخيارات بعد -s -- عند استخدام pipe، أو مباشرةً بعد اسم الملف عند تشغيل نسخة محلية. الخيارات المفيدة هي: -f لتخطي اختبار القرص، و-i لتخطي اختبار الشبكة، و-g لتخطي Geekbench، و-r لتقليل عدد مواقع iperf3 إلى موقعين، و-j لطباعة النتائج بتنسيق JSON، و-w results.json لكتابة JSON إلى ملف.

bash yabs.sh -r -w yabs-run1.json

يجب معرفة أمرين قبل التشغيل الأول. يرفع Geekbench نتيجتك ويطبع عنوان URL عاماً على browser.geekbench.com، لذلك يستطيع أي شخص يملك هذا الرابط قراءة طراز CPU والنتائج. يتخطى -g هذا الاختبار بالكامل. ثانياً، تنقل مرحلة iperf3 حركة مرور فعلية إلى خوادم في عدة مناطق، ويُحتسب ذلك من حصة النطاق الترددي الشهرية. على اتصال بسرعة 1 Gbit/s، قد تنقل مرحلة الشبكة الكاملة عشرات الجيجابايت، لذلك استخدم -r مع حصة صغيرة، و-i على اتصال تُحتسب تكلفته وفق الاستخدام.

ماذا يعني كل جزء من مخرجات yabs

يشغّل قسم القرص fio بمزيج قراءة وكتابة بنسبة 50/50 باستخدام أربعة أحجام للكتل: 4k و64k و512k و1m. ويعرض IOPS، أي عدد عمليات الإدخال والإخراج في الثانية، وعرض النطاق الترددي لكل حجم. صف 4k هو الأهم لقاعدة البيانات أو خادم البريد أو أي خدمة تنفّذ عمليات كتابة صغيرة كثيرة، لأن معظم عمليات الإدخال والإخراج في الخوادم صغيرة ومتفرقة. أما صف 1m فهو الأنسب للنسخ الاحتياطية والفيديو، حيث تنقل سلاسل طويلة من وحدات البايت.

يشغّل قسم الشبكة iperf3 مقابل خوادم عامة في عدة مناطق، وفي الاتجاهين، باستخدام تدفقات متوازية. اعتبر الرقم المنخفض هنا سبباً لطرح سؤال، لا إجابة نهائية، لأن خوادم iperf3 العامة مشتركة وغالباً ما تكون مشبعة. لذلك قد يكون سبب النتيجة الضعيفة في الطرف البعيد.

يعرض قسم Geekbench نتيجة لنواة واحدة ونتيجة لعدة أنوية. وتوضح نتيجة النواة الواحدة مدى سرعة إكمال طلب واحد أو عملية ترجمة واحدة أو استعلام واحد. أما نتيجة عدة أنوية فتوضح غالباً عدد الأنوية التي حصلت عليها فعلياً.

القرص: شغّل fio بنفسك

fio (أداة اختبار الإدخال والإخراج المرنة) هي الأداة التي يعمل بها قسم القرص في yabs، وتشغيلها مباشرة هو ما يجعل الخيارات ذات معنى فعلي.

sudo apt update && sudo apt install -y fio sysbench iperf3

اختبار قراءة عشوائية بحجم 4k وعمق قائمة انتظار قدره 32، على نظام الملفات الذي يهمك فعلياً:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

يبدو سطر الملخص الذي ينبغي قراءته من المخرجات كما يلي.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

يطبع fio أسفله كتلة clat percentiles. المئين 99.00 هو الرقم الذي يستحق الذكر، لأنه يوضح مدة انتظار أبطأ طلب واحد من كل 100 طلب. يخفي متوسط زمن الاستجابة حالات التوقف التي يلاحظها المستخدم تحديداً.

• --direct=1 يفتح الملف باستخدام O_DIRECT، لذلك تتجاوز القراءات ذاكرة التخزين المؤقت للصفحات في النواة. من دونه، تُخدَّم الجولة الثانية على ملف بحجم 2G من الذاكرة على جهاز يملك 8G من RAM، ويبلغ fio عن IOPS بالملايين. هذا الرقم حقيقي، لكنه يقيس الذاكرة.
• --ioengine=libaio يرسل الطلبات غير المتزامنة، وهذا ما يتيح لـ --iodepth=32 إبقاء 32 طلباً قيد التنفيذ. عند استخدام محرك متزامن مثل psync، لا يفعل iodepth الأكبر من 1 أي شيء، لذلك تقيس طلباً واحداً في كل مرة.
• --time_based --runtime=60 يشغّل الاختبار لمدة ثابتة قدرها 60 ثانية بدلاً من كمية عمل ثابتة، لذلك يحصل القرص السريع والقرص البطيء على نفس زمن الساعة، وتبقى المقارنة عادلة.
• --size=2G يحدد حجم ملف الاختبار. أبقه أكبر من أي ذاكرة تخزين مؤقت في المسار، وتحقق أولاً من توفر المساحة الحرة.

الكتابة العشوائية تستخدم الأمر نفسه مع --rw=randwrite. شغّلها بشكل منفصل، ثم احذف الملف.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

لاختبار مزيج أقرب إلى حركة الشبكة الفعلية، استخدم --rw=randrw --rwmixread=70. يغيّر نوع التخزين الذي يعمل عليه جهازك هذه النتائج أكثر من أي خيار، ويُشرح هذا الفرق في الفرق بين تخزين NVMe وتخزين SATA SSD على VPS.

عندما يتوقف fio مع الخطأ Unknown error -1

لا تتوفر عمليات الإدخال والإخراج المباشر على كل نظام ملفات. لا يدعم overlay، وهو نظام الملفات الذي يمنحه Docker للحاوية افتراضياً، وعدة أنظمة ملفات شبكية O_DIRECT، لذلك يرسل libaio طلباً لا يستطيع kernel إكماله، ويتوقف fio:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

شغّل df -hT . أولاً. إذا كان عمود Type يعرض overlay، فاجعل --filename يشير إلى مسار على وحدة تخزين فعلية، مثل volume مركّب عبر bind mount، أو شغّل fio على المضيف بدلاً من الحاوية. إذا تعذر الوصول إلى وحدة تخزين فعلية، فإن التشغيل المتزامن باستخدام التخزين المؤقت يثبت على الأقل أن الأمر نفسه صحيح.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

كن واضحاً بشأن ما يثبته هذا التشغيل. بعد المرور الأول، يبقى الملف بحجم 256M في page cache، لذلك يصف رقم IOPS ذاكرة RAM لديك. استخدمه للتأكد من تثبيت fio ومن تحليل الخيارات بنجاح. لا تعرضه أبداً على أنه نتيجة للقرص.

لماذا لا يُعدّ dd اختباراً معيارياً للقرص

يظهر dd في كثير من نقاشات VPS، وهو يجيب عن سؤال واحد محدود.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

يقيس ذلك معدل نقل الكتابة التسلسلية باستخدام خيط واحد وطلب واحد قيد التنفيذ. وهو اختبار معقول للتحقق الأولي. لكنه لا يقول شيئاً عن عمليات الإدخال والإخراج العشوائية، ولا عن سلوك النظام عند وصول 32 طلباً في الوقت نفسه. احذف oflag=direct، وسيقيس الاختبار في الغالب مدى سرعة قبول kernel لعمليات الكتابة في الذاكرة، ولذلك تكون قيم dd المذكورة في منشورات المنتديات مبالغاً فيها غالباً.

CPU: ‏sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

القيمة التي يجب الاحتفاظ بها هي events per second. شغّل الاختبار بخيط تنفيذ واحد أولاً. هذا هو الرقم الذي يحدد سرعة إكمال طلب PHP واحد أو مهمة ترجمة واحدة، وهو أكثر ما يختلف بين الخوادم ذات السعر نفسه. ثم شغّله باستخدام جميع الخيوط، لمعرفة ما إذا كانت vCPUs لديك تمثل أنوية منفصلة أم شرائح زمنية من نواة واحدة.

كن واضحاً بشأن ما يقيسه هذا الاختبار: يبحث sysbench cpu مراراً عن أعداد أولية باستخدام حسابات أعداد صحيحة بعرض 64 بت. ولا يضغط على عرض نطاق الذاكرة أو وحدات المتجهات أو ذاكرة التخزين المؤقت بطريقة تشبه حمل عمل حقيقياً. لذلك فهو مناسب لترتيب خادمين، لكنه غير مناسب للتنبؤ بكيفية تشغيل تطبيقك.

توفّر Ubuntu 24.04 الإصدار 1.0.20 من sysbench، حيث يأتي اسم الاختبار أولاً. إذا نسخت أمراً يتضمن --test=cpu من منشور قديم، فستحصل على WARNING: the --test option is deprecated. لا يمكن مقارنة النتائج من sysbench 0.4 وsysbench 1.0 إطلاقاً، لذلك لا تقارن نفسك أبداً برقم منشور لا يذكر إصداره.

الذاكرة: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

تكون النتيجة بوحدة MiB/sec، وتكون عمليات القراءة أسرع من الكتابة على كل جهاز. أبقِ --memory-block-size مضبوطاً على 1M، واستخدم القيمة نفسها تماماً على كل مضيف تقارنه. عند استخدام 1K ينهار الرقم، لأنك تتحمل النفقات العامة لكل عملية بمعدل يزيد 1000 مرة، فتقيس في النهاية تكلفة الحلقة بدلاً من عرض نطاق الذاكرة. هذا هو الخيار الذي يختلف أكثر من غيره في نتائج الذاكرة المنشورة.

الشبكة: iperf3

الطريقة الدقيقة لاختبار معدل النقل هي الاختبار مقابل جهاز ثانٍ تديره أنت، لأنك تعرف عندها ما الذي يحدث على الطرفين.

على الطرف البعيد:

iperf3 -s

يستمع هذا الأمر على TCP 5201. افتح المنفذ للعنوان الذي تختبر منه فقط، وأغلقه عند الانتهاء. يشرح قواعد جدار الحماية الأساسية في ufw على VPS الصياغة.

من VPS قيد الاختبار:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

يقيس الأمر الأول سرعة الرفع من الجهاز قيد الاختبار. يعكس -R الاتجاه، وبذلك يقيس سرعة التنزيل. يفتح -P 8 ثمانية تدفقات متوازية.

شغّل كلاً من التدفق الواحد والإصدار المتوازي، لأن كل واحد منهما يجيب عن سؤال مختلف. لا يمكن لاتصال TCP واحد الاحتفاظ إلا بقدر البيانات غير المؤكدة الذي تسمح به نافذته، لذلك يكون حدّه الأعلى تقريباً حجم النافذة مقسوماً على زمن الذهاب والإياب. عند زمن انتقال قدره 80 ms ونافذة بحجم 4 MB، يكون هذا الحد الأعلى نحو 400 Mbit/s، مهما كانت سرعة الرابط الأساسية. تخبرك قيمة التدفق الواحد بما سيحصل عليه تنزيل واحد. أما قيمة التدفقات المتوازية فتخبرك بسعة الرابط.

راقب حصة النطاق الترددي لديك أثناء ذلك. يؤدي تشغيل لمدة 30 ثانية بسرعة 1 Gbit/s إلى نقل نحو 3.75 GB، وستشغّل الاختبار عدة مرات في كل اتجاه.

الأرقام المرجعية وكيفية قراءة نتائجك

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

يصل أداء وحدة تخزين NVMe المحلية في النتائج المنشورة عادةً إلى نحو 180,000 من IOPS للقراءة العشوائية بحجم 4k. ويبلغ أداء SSD محلي من نوع SATA نحو 90,000. أما تخزين الكتل المتصل بالشبكة، حيث يعبر كل طلب الشبكة قبل وصوله إلى القرص، فيقترب من 12,000، بينما يحقق القرص الميكانيكي نحو 180، لأنه يحرّك الرأس الفعلي لكل طلب عشوائي.

هذه أرقام منشورة نموذجية لكل فئة من فئات التخزين، وليست قياسات من خادم واحد. استخدمها لغرض واحد: التحقق من أن نتيجتك تقع ضمن نطاق الحجم الصحيح. إذا كانت الخطة المباعة على أنها NVMe تحقق في الاختبار بضع آلاف فقط من IOPS للقراءة العشوائية بحجم 4k، فتحقق أولاً من أن --direct=1 كان مفعّلاً. إذا كان مفعّلاً، فإما أن التخزين ليس كما تصفه صفحة المنتج، أو أنك تشاركه مع جار يستهلك الموارد بكثافة.

لماذا لا تُعدّ نتيجة واحدة معياراً للأداء

النتيجة الواحدة هي لقطة لدقيقة واحدة على جهاز مشترك. تعامل معها على أنها عينة واحدة.

• شغّل كل اختبار 5 مرات على الأقل، ووزّع التشغيل على ساعات مختلفة وعلى يومين مختلفين على الأقل. احتفظ بالوسيط وبمدى النتائج. النتيجة المنشورة من دون مدى هي رقم تسويقي.
• سجّل وقت steal بجانب كل تشغيل. استبعد عمليات التشغيل التي كانت فيها st مرتفعة، أو اذكر ذلك على الأقل.
• شغّل اختبار القرص بمدتين مختلفتين. تمنح خطط كثيرة حصة burst من IOPS تُعاد تعبئتها بمرور الوقت، لذلك يقيس تشغيل fio لمدة 60 ثانية أداء burst، بينما يقيس --runtime=600 الحد الأدنى للأداء. هذا الحد الأدنى هو الأداء الذي تحصل عليه في يوم سيئ.
• تحقّق من عدم تشغيل أي شيء آخر. إن بدء unattended-upgrades معاملة apt أثناء اختبار CPU يخصم نقاطاً فعلية منك، كما أن تشغيل ps -e -o comm= | grep -E 'apt|dpkg' قبل كل اختبار يستغرق ثانية واحدة.
• غيّر متغيراً واحداً في كل مرة. تنتج إصدارات الأدوات أو أحجام الكتل أو أعداد مؤشرات الترابط المختلفة أرقاماً لا يمكن مقارنتها، مهما بدت متشابهة.

عند مقارنة موفّرين، شغّل الاختبارين في الساعة نفسها من اليوم نفسه. وإلا فأنت تقيس وقت اليوم.

قِس أداء حملك الفعلي أخيراً

تُرتّب الأدوات الاصطناعية الأجهزة. لكن حملك الفعلي وحده يوضح ما إذا كان الجهاز كافياً. قِس زمن العملية التي تنفذها فعلياً.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

تضغط هذه العملية بضع مئات من الميغابايت، ولذلك تختبر المعالج والقرص معاً، وتتغير نتيجتها عند تغير أيٍّ منهما. تحذير Removing leading / from member names طبيعي. والأفضل من ذلك أن تقيس زمن عملية البناء الخاصة بك، أو أبطأ استعلام لديك، أو عرض صفحتك الفعلي. إذا استغرقت عملية البناء 4 دقائق على أحد المضيفين و7 دقائق على مضيف آخر، فقد حُسم الأمر، بصرف النظر عما أظهره Geekbench. وهذا هو القياس الذي يوضح أيضاً متى لا تعود زيادة موارد الجهاز تستحق التكلفة، ومن المفيد معرفة ذلك قبل أن تقرأ التكلفة الشهرية الفعلية لـVPS أو تنقل حمل العمل إلى خادم مخصص.

FAQ

لماذا أحصل على نتيجة مختلفة للاختبار المعياري في كل مرة أشغّله؟

تشارك VPS وحدة المعالجة المركزية والتخزين والشبكة الفعلية مع مستأجرين آخرين، لذلك تعتمد نتيجتك على ما يفعلونه في تلك اللحظة. شغّل vmstat 1 أثناء الاختبار واقرأ عمود st: إذا تجاوز وقت steal المستمر 5، فهذا يعني أن المضيف كان مشغولاً، وأن نتيجة CPU لديك منخفضة لأسباب خارج جهازك. الحل هو اتباع منهج ثابت، وليس ضبط الإعدادات. شغّل كل اختبار 5 مرات أو أكثر خلال ساعات مختلفة، ثم أبلغ عن الوسيط مع نطاق القيم.

لماذا يعرض fio ملايين IOPS؟

يحدث ذلك غالباً لأن --direct=1 مفقود. من دونه، يقرأ fio عبر page cache الخاصة بالنواة. لذلك، بعد المرور الأول، يُخدَّم ملف اختبار بحجم 2G من RAM، وتكون قد قست عرض نطاق الذاكرة. أضف --direct=1 واجعل ملف الاختبار أكبر من أي cache في المسار. إذا فشل --direct=1 بعد ذلك مع err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1، فشغّل df -hT .: إن Type من overlay لا يدعم O_DIRECT، لذا وجّه الاختبار إلى التخزين الفعلي بدلاً من ذلك.

هل يكفي yabs.sh بمفرده؟

نعم، لإجراء فحص أولي. فهو يشغّل fio بأربعة أحجام للكتل، وiperf3 في الاتجاهين، وGeekbench، ويطبع ملخصاً واحداً يمكن للآخرين قراءته. لكنه لا يعود كافياً عندما تريد معرفة سبب نتيجة معينة، لأنك لا تستطيع تغيير flags لكل اختبار. عندما تبدو نتيجة yabs غير صحيحة، أعد إنتاجها باستخدام fio أو sysbench مباشرة، وغيّر flag واحداً في كل مرة.

ما الرقم الوحيد الذي يتنبأ بكيفية أداء تطبيقي؟

تأتي سرعة النواة الواحدة أولاً، ثم زمن استجابة القراءة العشوائية بحجم 4k، وذلك لمعظم أعباء الويب وقواعد البيانات. تبدو أرقام معدل النقل مثيرة للإعجاب، لكنها نادراً ما تحسم النتيجة، لأن الطلب المعتاد صغير. أبلغ عن المئين 99 من كتلة clat percentiles في fio بدلاً من المتوسط، لأن الطلب البطيء من كل 100 طلب هو ما يلاحظه المستخدم.

هل أحتاج إلى تثبيت أي شيء قبل إجراء الاختبار المعياري؟

توجد fio وsysbench وiperf3 جميعاً في مستودعات Ubuntu وDebian: sudo apt install -y fio sysbench iperf3. لا يحتاج yabs.sh إلا إلى curl، لأنه ينزّل ملفات ثنائية ثابتة لأي مكوّن مفقود. احذف كل ملف اختبار عند الانتهاء، لأن ترك ملف fio بحجم 2G على قرص سعته 20G قد يؤدي إلى ظهور تنبيه امتلاء القرص بعد أسابيع.