كيفية اختبار أداء VPS بشكل صحيح

ما المقصود باختبار أداء 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 المحاكاة الافتراضية الكاملة، ولذلك تشغّل نواتك الخاصة. أما طباعة lxc أو openvz بواسطة systemd-detect-virt فتعني المحاكاة الافتراضية للحاويات بدلاً من ذلك: أنت تشارك نواة المضيف، وتكون حدود وحدة المعالجة المركزية والذاكرة إعدادات cgroup (مجموعة التحكم)، وليست عتاداً افتراضياً. في نظام يستخدم cgroup v2، يمكنك قراءة حد وحدة المعالجة المركزية مباشرةً.

cat /sys/fs/cgroup/cpu.max

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

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

راقب وقت الاقتطاع طوال الوقت

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

vmstat 1 10

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

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

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

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

curl -sL yabs.sh | bash

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

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، لا يفعل عمق الإدخال والإخراج الأكبر من 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 يشير إلى مسار على وحدة تخزين فعلية، مثل وحدة تخزين مرتبطة عبر 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 في ذاكرة التخزين المؤقت للصفحات، ولذلك يصف رقم 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، فإنه يقيس غالبًا مدى سرعة قبول نواة النظام لعمليات الكتابة في الذاكرة، ولذلك تكون أرقام 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 الإصدار sysbench 1.0.20، حيث يأتي اسم الاختبار أولًا. إذا نسخت أمرًا يتضمن --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، ينهار الرقم لأنك تتحمل النفقات العامة لكل عملية عددًا من المرات أكبر بألف مرة، فتقيس في النهاية تكلفة الحلقة بدلًا من عرض نطاق الذاكرة. هذا هو الخيار الذي يختلف غالبًا بين نتائج الذاكرة المنشورة.

الشبكة: 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 من عمليات الإدخال والإخراج في الثانية للقراءة العشوائية بحجم 4k. ويحقق قرص SATA SSD محلي نحو 90,000. أما التخزين الكتلي المتصل عبر الشبكة، حيث يعبر كل طلب الشبكة قبل وصوله إلى القرص، فيحقق عادةً نحو 12,000، بينما يحقق القرص الميكانيكي نحو 180، لأنه يحرك رأسًا فعليًا لكل طلب عشوائي.

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

لماذا لا تُعدّ عملية تشغيل واحدة اختبارًا معياريًا

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

• شغّل كل اختبار 5 مرات على الأقل، ووزّع عمليات التشغيل على ساعات مختلفة ويومين مختلفين على الأقل. احتفظ بالوسيط وبمدى التشتت. النتيجة المنشورة من دون مدى تشتت هي رقم تسويقي.
• سجّل وقت steal بجانب كل عملية تشغيل. استبعد عمليات التشغيل التي كانت فيها قيمة st مرتفعة، أو اذكر ذلك على الأقل.
• شغّل اختبار القرص بمدتين مختلفتين. تمنح خطط كثيرة مخصصًا للدفعة من IOPS يُعاد ملؤه بمرور الوقت، لذلك تقيس عملية تشغيل fio لمدة 60 ثانية الدفعة، بينما تقيس --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: إذا تجاوز وقت السرقة المستمر 5، فهذا يعني أن المضيف كان مشغولًا، وأن نتيجة CPU لديك منخفضة لأسباب خارج جهازك. الحل هو اتباع منهج ثابت، وليس ضبط الإعدادات. شغّل كل اختبار 5 مرات أو أكثر خلال ساعات مختلفة، ثم أبلغ عن الوسيط مع نطاق التباين.

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

يحدث ذلك غالبًا لأن --direct=1 مفقود. من دونه، يقرأ fio من ذاكرة التخزين المؤقت للصفحات في النواة. لذلك، بعد المرور الأول، يُخدَّم ملف اختبار بحجم 2G من RAM، وتكون قد قست عرض نطاق الذاكرة. أضف --direct=1 واجعل ملف الاختبار أكبر من أي ذاكرة تخزين مؤقت في المسار. إذا فشل --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، ثم يطبع ملخصًا يمكن للآخرين قراءته. لكنه لا يعود كافيًا عندما تريد معرفة سبب قيمة معينة، لأنك لا تستطيع تغيير الأعلام لكل اختبار على حدة. عندما تبدو نتيجة yabs غير صحيحة، أعد الاختبار باستخدام fio أو sysbench مباشرة، وغيّر علمًا واحدًا في كل مرة.

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

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

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

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