วิธีทดสอบประสิทธิภาพ VPS ให้ได้ผลที่เชื่อถือได้

ความหมายของการทดสอบประสิทธิภาพ VPS

การทดสอบประสิทธิภาพ VPS คือการวัด 4 รายการ ได้แก่ ความเร็วของการทำงานบน CPU core เดียว แบนด์วิดท์หน่วยความจำของเครื่อง จำนวนการดำเนินการกับดิสก์แบบสุ่มขนาดเล็กที่ storage ให้บริการได้ต่อวินาที และ throughput ที่ network link ส่งมอบได้ การเรียกใช้ yabs.sh 1 ครั้งจะให้ผลลัพธ์ทั้ง 4 รายการภายในเวลาประมาณ 10 นาที การอ่านผลลัพธ์เป็นส่วนที่ยากกว่า เนื่องจาก VPS (virtual private server) ใช้ hardware จริงร่วมกับผู้เช่ารายอื่น ดังนั้นเครื่องเดียวกันอาจรายงานค่าหนึ่งเมื่อเวลา 03:00 และรายงานค่าที่แตกต่างอย่างมากเมื่อเวลา 20:00

แผนคือเรียกใช้ yabs.sh เพื่อดูภาพรวมอย่างรวดเร็ว จากนั้นจึงเรียกใช้เครื่องมือที่อยู่เบื้องหลังด้วยตนเอง การเรียกใช้เครื่องมือเหล่านี้ด้วยตนเองช่วยให้คุณเปลี่ยน flag ทีละรายการ ตรวจสอบว่าค่าที่วัดได้เปลี่ยนแปลงอย่างไร และทำความเข้าใจว่าค่านั้นวัดอะไรจริง ๆ ให้ดำเนินการหลังจากตั้งค่าเครื่องเสร็จแล้ว ไม่ใช่ก่อนหน้านั้น ขั้นตอนใน 10 นาทีแรกบน VPS ใหม่ ต้องทำก่อน เนื่องจากเครื่องที่ยังติดตั้ง updates ชุดแรกอยู่จะให้ผลการทดสอบประสิทธิภาพที่ไม่ดี ด้วยเหตุผลที่ไม่เกี่ยวข้องกับ hardwareเลย

ตรวจสอบเครื่องก่อนวัดประสิทธิภาพ

ครึ่งหนึ่งของการทดสอบประสิทธิภาพที่ผิดพลาดเกิดจากผู้จัดทำไม่เข้าใจเครื่องที่ใช้ทดสอบ

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

Hypervisor vendor: KVM หมายถึงการทำเวอร์ชวลไลเซชันแบบเต็มรูปแบบ ดังนั้นคุณจึงใช้ kernel ของตนเอง ส่วน systemd-detect-virt ที่แสดง lxc หรือ openvz หมายถึงการทำเวอร์ชวลไลเซชันแบบ container แทน คุณใช้ kernel ร่วมกับเครื่องโฮสต์ และขีดจำกัด CPU กับหน่วยความจำเป็นการตั้งค่า cgroup (control group) ไม่ใช่ฮาร์ดแวร์เสมือน ในระบบ cgroup v2 คุณสามารถอ่านขีดจำกัด CPU ได้โดยตรง

cat /sys/fs/cgroup/cpu.max

max 100000 หมายถึงไม่มีโควตา 200000 100000 หมายถึงคุณสามารถใช้ CPU ได้ 200000 ไมโครวินาทีในทุกช่วงเวลา 100000 ไมโครวินาที ซึ่งเทียบเท่ากับโควตา 2 core แผนบริการที่โฆษณาว่ามี 4 vCPU แต่กำหนดโควตาไว้ที่ 2 core จะไม่มีทางได้คะแนนเทียบเท่า 4 core และไม่มีเครื่องมือทดสอบประสิทธิภาพใดแสดงบรรทัดที่บอกเหตุผลให้คุณทราบ

df -hT / มีความสำคัญด้วยเหตุผลอื่น นั่นคือคอลัมน์ Type หากแสดงค่า overlay แสดงว่าคุณอยู่ภายใน container และการทดสอบดิสก์ด้านล่างต้องปรับเปลี่ยน ให้จดจำข้อนี้ไว้ตอนนี้

เฝ้าติดตาม steal time ตลอดช่วงการทดสอบ

Steal time คือสัดส่วนเวลาที่ virtual CPU ของคุณพร้อมทำงาน แต่ hypervisor จัดสรร physical core ให้กับผู้ใช้งานรายอื่น ตัวเลขนี้เป็นสัญญาณเดี่ยวที่มีประโยชน์ที่สุดในการระบุว่าผลลัพธ์ได้รับผลกระทบจากผู้ใช้งานรายอื่นหรือจาก hardware

vmstat 1 10

อ่านคอลัมน์ st ทางด้านขวา ค่า 0 หรือ 1 อย่างต่อเนื่องถือเป็นเรื่องปกติ ค่าที่สูงกว่า 5 ต่อเนื่องหมายความว่า host มีการจัดสรรทรัพยากรเกินขนาดในขณะนั้น ดังนั้นค่าการใช้งาน CPU ทุกค่าที่บันทึกในช่วงเวลาดังกล่าวจะต่ำลงโดยไม่ได้เกิดจากปัญหาของเครื่องของคุณ top แสดงค่าเดียวกับ %st ในบรรทัด CPU เปิดให้ vmstat 1 ทำงานใน SSH session ที่สองขณะทำ benchmark และจดค่า steal ไว้ถัดจากผลลัพธ์แต่ละรายการ

เริ่มต้นด้วย yabs.sh

yabs.sh (Yet Another Bench Script) เป็น shell script ที่ดาวน์โหลดไบนารีแบบ static ของ 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

เมื่อใช้ pipe ให้ใส่ flags ต่อจาก -s -- หรือเมื่อเรียกใช้ไฟล์ในเครื่อง ให้ใส่ flags ต่อจากชื่อไฟล์โดยตรง flags ที่มีประโยชน์ ได้แก่ -f เพื่อข้ามการทดสอบดิสก์, -i เพื่อข้ามการทดสอบเครือข่าย, -g เพื่อข้าม Geekbench, -r เพื่อลดจำนวนตำแหน่งทดสอบของ iperf3 เหลือ 2 แห่ง, -j เพื่อแสดงผลลัพธ์เป็น JSON และ -w results.json เพื่อเขียน JSON ลงในไฟล์

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

มี 2 เรื่องที่ควรทราบก่อนเรียกใช้ครั้งแรก Geekbench จะอัปโหลดผลลัพธ์และแสดง URL สาธารณะของ browser.geekbench.com ดังนั้นผู้ที่มีลิงก์ดังกล่าวจะสามารถดูรุ่น CPU และคะแนนของคุณได้ -g จะข้ามการทดสอบนี้ทั้งหมด ประการที่สอง ขั้นตอน iperf3 จะส่ง network traffic จริงไปยังเซิร์ฟเวอร์ในหลายภูมิภาค และปริมาณดังกล่าวจะถูกนับรวมในโควตาแบนด์วิดท์รายเดือนของคุณ บนลิงก์ความเร็ว 1 Gbit/s การทดสอบเครือข่ายแบบเต็มอาจใช้ปริมาณข้อมูลหลายสิบ GB ดังนั้นให้ใช้ -r หากมีโควตาจำกัด และใช้ -i หากคิดค่าบริการตามปริมาณการใช้งาน

ความหมายของแต่ละส่วนในผลลัพธ์จาก yabs

ส่วนดิสก์จะเรียกใช้ fio โดยแบ่งการอ่านและการเขียนในสัดส่วน 50/50 ที่ขนาดบล็อก 4k, 64k, 512k และ 1m รายงานค่า IOPS (การดำเนินการอินพุต/เอาต์พุตต่อวินาที) และแบนด์วิดท์ของแต่ละขนาด แถว 4k เป็นค่าที่ควรให้ความสำคัญสำหรับฐานข้อมูล เมลเซิร์ฟเวอร์ หรือระบบที่เขียนข้อมูลขนาดเล็กจำนวนมาก เนื่องจาก IO ส่วนใหญ่ของเซิร์ฟเวอร์มีขนาดเล็กและกระจัดกระจาย แถว 1m เหมาะสำหรับการสำรองข้อมูลและวิดีโอ ซึ่งเป็นงานที่ย้ายข้อมูลต่อเนื่องเป็นช่วงยาว

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

ส่วน Geekbench จะแสดงคะแนนแบบ single core และ multi core คะแนนแบบ single core ใช้คาดการณ์ความเร็วที่คำขอหนึ่งรายการ การคอมไพล์หนึ่งครั้ง หรือคิวรีหนึ่งรายการเสร็จสิ้น ส่วนคะแนนแบบ multi core ใช้บ่งชี้เป็นหลักว่าคุณได้รับ core จริงจำนวนเท่าใด

Disk: เรียกใช้ fio ด้วยตนเอง

fio (flexible IO tester) เป็นเครื่องมือที่อยู่เบื้องหลังส่วน disk ของ yabs และการเรียกใช้โดยตรงจะทำให้เข้าใจความหมายของ flag ต่าง ๆ ได้ชัดเจน

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

การทดสอบการอ่านแบบสุ่มขนาด 4k ที่ queue depth 32 บน filesystem ที่ต้องการตรวจสอบจริง:

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 เป็นค่าที่ควรนำไปอ้างอิง เพราะแสดงเวลาที่ request ที่ช้าที่สุด 1 รายการจาก 100 รายการต้องรอ ค่า latency เฉลี่ยจะไม่แสดงช่วงหยุดชะงักที่ผู้ใช้สังเกตเห็นได้อย่างชัดเจน

• --direct=1 เปิดไฟล์ด้วย O_DIRECT ทำให้การอ่านข้าม kernel page cache หากไม่มีตัวเลือกนี้ การอ่านรอบที่สองของไฟล์ขนาด 2G บนเครื่องที่มี RAM 8G จะอ่านจากหน่วยความจำ และ fio จะแสดงค่า IOPS เป็นหลักล้าน ค่านี้เป็นค่าจริง แต่เป็นค่าที่วัดจากหน่วยความจำ
• --ioengine=libaio ส่ง asynchronous requests ซึ่งทำให้ --iodepth=32 มี request ที่กำลังดำเนินการพร้อมกัน 32 รายการได้ ด้วย synchronous engine เช่น psync ค่า iodepth ที่มากกว่า 1 จะไม่มีผลใด ๆ ดังนั้นการทดสอบจะวัดทีละ request
• --time_based --runtime=60 กำหนดให้การทดสอบทำงานเป็นเวลา 60 วินาที แทนการกำหนดปริมาณงานตายตัว ทำให้ดิสก์ที่เร็วและดิสก์ที่ช้าใช้เวลาเท่ากัน และการเปรียบเทียบมีความเป็นธรรม
• --size=2G กำหนดขนาดไฟล์ทดสอบ ให้ขนาดใหญ่กว่า cache ทุกจุดในเส้นทางการอ่านเขียน และตรวจสอบพื้นที่ว่างก่อน

การเขียนแบบสุ่มใช้คำสั่งเดียวกัน โดยเปลี่ยนเป็น --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

หากต้องการรูปแบบที่ใกล้เคียงกับ network traffic จริงมากขึ้น ให้ใช้ --rw=randrw --rwmixread=70 ประเภทของ storage ที่ใช้งานอยู่ส่งผลต่อผลลัพธ์เหล่านี้มากกว่า flag ใด ๆ และความแตกต่างดังกล่าวอธิบายไว้ใน ความแตกต่างระหว่าง NVMe และ SATA SSD storage บน VPS

เมื่อ fio หยุดทำงานด้วย Unknown error -1

Direct IO ไม่พร้อมใช้งานบน filesystem ทุกประเภท overlay ซึ่งเป็น filesystem ที่ Docker มอบให้ container ตามค่าเริ่มต้น และ filesystem ผ่านเครือข่ายหลายประเภทไม่รองรับ 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 ไปยัง path บน storage จริง เช่น volume ที่ bind mount ไว้ หรือเรียกใช้ fio บน host แทนการเรียกใช้ใน container หากไม่สามารถเข้าถึง storage จริงได้ การทดสอบแบบ synchronous ที่ใช้ buffered IO ยังช่วยยืนยันได้อย่างน้อยว่าคำสั่งถูกต้อง

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 แล้วและระบบแปลความหมายของ flags ได้ถูกต้อง ห้ามนำผลนี้ไปอ้างว่าเป็นผลลัพธ์ของ disk

เหตุใด dd จึงไม่ใช่เครื่องมือทดสอบประสิทธิภาพดิสก์

dd ปรากฏอยู่ในกระทู้เกี่ยวกับ VPS จำนวนมาก และใช้ตอบคำถามได้เพียงประเด็นเดียว

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

คำสั่งนี้วัดอัตราการเขียนข้อมูลแบบลำดับต่อเนื่อง โดยใช้ 1 thread และมีคำขอที่อยู่ระหว่างดำเนินการ 1 รายการ เป็นการตรวจสอบเบื้องต้นที่เหมาะสม แต่ไม่ให้ข้อมูลเกี่ยวกับ random IO และไม่แสดงผลเมื่อมีคำขอเข้ามาพร้อมกัน 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 ให้รันแบบ single threaded ก่อน ค่านี้บ่งชี้ว่า PHP request หนึ่งรายการจะเสร็จสิ้นเร็วเพียงใด หรืองาน compile หนึ่งงานจะเสร็จสิ้นเร็วเพียงใด และเป็นค่าที่แตกต่างกันระหว่างโฮสต์ที่มีราคาเท่ากันมากที่สุด จากนั้นให้รันโดยใช้ทุก thread เพื่อดูว่า vCPU ของคุณเป็น core แยกกัน หรือเป็นส่วนแบ่งของ core เดียว

ควรเข้าใจอย่างชัดเจนว่าการทดสอบนี้วัดอะไร: sysbench cpu จะคำนวณหาจำนวนเฉพาะซ้ำ ๆ โดยใช้การคำนวณจำนวนเต็มขนาด 64 bit การทดสอบนี้ไม่ได้ทดสอบ memory bandwidth, vector unit หรือ cache ในลักษณะที่ใกล้เคียงกับ workload จริง ดังนั้นจึงเหมาะสำหรับจัดอันดับโฮสต์ 2 เครื่อง แต่ไม่เหมาะสำหรับคาดการณ์ว่า application ของคุณจะทำงานอย่างไร

Ubuntu 24.04 มาพร้อม sysbench 1.0.20 ซึ่งชื่อการทดสอบต้องอยู่ก่อน หากคัดลอกคำสั่งที่มี --test=cpu จากโพสต์เก่า คุณจะได้ WARNING: the --test option is deprecated คะแนนจาก sysbench 0.4 และ sysbench 1.0 ไม่สามารถนำมาเปรียบเทียบกันได้เลย ดังนั้นอย่าเปรียบเทียบผลของคุณกับค่าที่เผยแพร่ไว้ หากค่าดังกล่าวไม่ได้ระบุ version

หน่วยความจำ: 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 ค่าผลลัพธ์จะลดลงอย่างมาก เนื่องจากมีค่าใช้จ่ายต่อการดำเนินการเพิ่มขึ้น 1,000 เท่า จึงกลายเป็นการวัดต้นทุนของลูปแทนแบนด์วิดท์หน่วยความจำ นี่คือ flag ที่มักกำหนดไม่ตรงกันมากที่สุดในคะแนนการทดสอบหน่วยความจำที่เผยแพร่แล้ว

Network: 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 เปิดสตรีมแบบขนาน 8 รายการ

ให้เรียกใช้ทั้งแบบสตรีมเดียวและแบบขนาน เพราะแต่ละแบบตอบคำถามคนละข้อ การเชื่อมต่อ TCP รายการเดียวจะรองรับข้อมูลที่ยังไม่ได้รับการยืนยันได้ไม่เกินขนาดที่หน้าต่างกำหนด ดังนั้นค่าสูงสุดจะอยู่ที่ประมาณขนาดหน้าต่างหารด้วยเวลาไปกลับ เมื่อมีเวลาแฝง 80 ms และหน้าต่างขนาด 4 MB ค่าสูงสุดจะอยู่ที่ประมาณ 400 Mbit/s ไม่ว่าลิงก์พื้นฐานจะเร็วเพียงใด ค่าจากสตรีมเดียวแสดงความเร็วที่การดาวน์โหลดรายการเดียวจะได้รับ ส่วนค่าจากการทำงานแบบขนานแสดงความจุของลิงก์

ตรวจสอบโควตาแบนด์วิดท์ของคุณระหว่างการทดสอบด้วย การรับส่งข้อมูลที่ความเร็ว 1 Gbit/s เป็นเวลา 30 วินาทีจะใช้ข้อมูลประมาณ 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 volume ภายในเครื่องตามผลการทดสอบที่เผยแพร่มักทำได้ใกล้เคียง 180,000 IOPS สำหรับการอ่านแบบสุ่มขนาด 4k ส่วน SATA SSD ภายในเครื่องทำได้ประมาณ 90,000 ขณะที่ block storage ที่เชื่อมต่อผ่านเครือข่าย ซึ่งทุกคำขอต้องเดินทางผ่านเครือข่ายก่อนถึงดิสก์ จะทำได้ใกล้เคียง 12,000 และดิสก์แบบจานหมุนทำได้ประมาณ 180 เนื่องจากต้องเลื่อนหัวอ่านเชิงกายภาพสำหรับทุกคำขอแบบสุ่ม

ตัวเลขเหล่านี้เป็นค่าทั่วไปที่เผยแพร่สำหรับ storage แต่ละประเภท ไม่ใช่ค่าที่วัดจากโฮสต์เครื่องใดเครื่องหนึ่ง ใช้ตัวเลขเหล่านี้เพื่อตรวจสอบว่าผลลัพธ์ของคุณอยู่ในระดับเดียวกันโดยประมาณ หากแผนที่ระบุว่าจำหน่ายเป็น NVMe ทำผลทดสอบได้เพียงหลักพันของ 4k IOPS ให้ตรวจสอบก่อนว่าเปิดใช้งาน --direct=1 อยู่หรือไม่ หากเปิดใช้งานแล้ว แสดงว่า storage อาจไม่ตรงกับที่หน้า product อธิบายไว้ หรือคุณกำลังใช้งานร่วมกับผู้ใช้รายอื่นที่มีภาระงานสูงมาก

เหตุใดการรันเพียงครั้งเดียวจึงไม่ใช่การทดสอบประสิทธิภาพ

ผลลัพธ์เพียงครั้งเดียวเป็นภาพรวมของหนึ่งนาทีบนเครื่องที่ใช้งานร่วมกับผู้อื่น ให้ถือว่าเป็นตัวอย่างเพียงหนึ่งตัวอย่าง

• เรียกใช้การทดสอบแต่ละรายการอย่างน้อย 5 ครั้ง โดยกระจายการทดสอบไปในช่วงเวลาที่แตกต่างกัน และอย่างน้อย 2 วัน เก็บค่ามัธยฐานและช่วงการกระจายไว้ ผลลัพธ์ที่เผยแพร่โดยไม่มีช่วงการกระจายเป็นตัวเลขเชิงการตลาด
• บันทึกเวลา steal ไว้ข้างผลการทดสอบแต่ละครั้ง ตัดผลการทดสอบที่ st มีค่าสูงออก หรืออย่างน้อยให้ระบุไว้ว่าเกิดกรณีดังกล่าว
• เรียกใช้การทดสอบดิสก์ที่ระยะเวลา 2 ค่า แผนบริการจำนวนมากให้สิทธิ์ burst IOPS ซึ่งจะเติมกลับเมื่อเวลาผ่านไป ดังนั้นการเรียกใช้ fio เป็นเวลา 60 วินาทีจะวัดช่วง burst ขณะที่ --runtime=600 จะวัดค่าพื้นฐาน ค่าพื้นฐานคือสิ่งที่คุณจะได้รับในวันที่ประสิทธิภาพแย่
• ตรวจสอบว่าไม่มีสิ่งอื่นกำลังทำงานอยู่ unattended-upgrades การเริ่มธุรกรรม apt ระหว่างการทดสอบ CPU จะทำให้คะแนนลดลงจริง และการเรียกใช้ ps -e -o comm= | grep -E 'apt|dpkg' ก่อนการทดสอบแต่ละครั้งใช้เวลาเพียงหนึ่งวินาที
• เปลี่ยนตัวแปรครั้งละ 1 รายการ เวอร์ชันของเครื่องมือ ขนาดบล็อก หรือจำนวนเธรดที่แตกต่างกันจะให้ตัวเลขที่ไม่สามารถนำมาเปรียบเทียบกันได้ แม้ตัวเลขจะดูคล้ายกันมากก็ตาม

เมื่อเปรียบเทียบผู้ให้บริการ 2 ราย ให้ทดสอบในชั่วโมงเดียวกันของวันเดียวกัน มิฉะนั้นคุณจะวัดช่วงเวลาของวันแทน

เปรียบเทียบประสิทธิภาพกับเวิร์กโหลดของคุณเองเป็นลำดับสุดท้าย

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

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

คำสั่งนี้บีบอัดข้อมูลขนาดไม่กี่ร้อยเมกะไบต์ จึงทดสอบทั้ง CPU และดิสก์พร้อมกัน และผลลัพธ์จะเปลี่ยนเมื่ออย่างใดอย่างหนึ่งเปลี่ยนแปลง คำเตือน Removing leading / from member names เป็นเรื่องปกติ แต่ควรจับเวลาการ build ของคุณเอง คิวรีที่ช้าที่สุดของคุณเอง หรือการเรนเดอร์หน้าเว็บของคุณเองจะดีกว่า หากการ build ใช้เวลา 4 นาทีบนโฮสต์หนึ่งและ 7 นาทีบนอีกโฮสต์หนึ่ง ก็เพียงพอที่จะตัดสินใจได้แล้ว ไม่ว่า Geekbench จะประเมินไว้อย่างไร การวัดนี้ยังบอกได้ด้วยว่าเมื่อใดการเพิ่มทรัพยากรเครื่องไม่คุ้มกับค่าใช้จ่ายอีกต่อไป ซึ่งควรทราบก่อนอ่าน VPS มีค่าใช้จ่ายจริงต่อเดือนเท่าใด หรือย้ายเวิร์กโหลดไปยัง เซิร์ฟเวอร์แบบ dedicated

FAQ

เหตุใดผลการทดสอบประสิทธิภาพจึงแตกต่างกันทุกครั้งที่เรียกใช้

VPS ใช้ CPU จริง พื้นที่จัดเก็บข้อมูล และเครือข่ายร่วมกับผู้ใช้งานรายอื่น ดังนั้นผลลัพธ์จึงขึ้นอยู่กับสิ่งที่ผู้ใช้งานเหล่านั้นกำลังทำอยู่ในขณะนั้น เรียกใช้ vmstat 1 ระหว่างการทดสอบและอ่านคอลัมน์ st หากค่า steal time ต่อเนื่องสูงกว่า 5 แสดงว่าโฮสต์กำลังมีภาระงานสูง และคะแนน CPU ของคุณต่ำด้วยเหตุผลที่อยู่นอกเครื่องของคุณ วิธีแก้คือปรับวิธีทดสอบ ไม่ใช่ปรับแต่งระบบ เรียกใช้การทดสอบแต่ละรายการอย่างน้อย 5 ครั้งในช่วงเวลาที่แตกต่างกัน แล้วรายงานค่ามัธยฐานพร้อมช่วงการกระจาย

เหตุใด fio จึงรายงานค่า IOPS หลายล้านรายการ

สาเหตุเกือบทุกครั้งคือไม่มี --direct=1 หากไม่มีตัวเลือกนี้ fio จะอ่านข้อมูลผ่าน page cache ของ kernel ดังนั้นหลังจากรอบแรก ไฟล์ทดสอบขนาด 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 เพียงอย่างเดียวเพียงพอหรือไม่

สำหรับการตรวจสอบเบื้องต้น เพียงพอ yabs.sh เรียกใช้ fio ด้วยขนาดบล็อก 4 แบบ เรียกใช้ iperf3 ทั้งสองทิศทาง และเรียกใช้ Geekbench จากนั้นจะแสดงสรุปผลที่ผู้อื่นสามารถอ่านได้ แต่จะไม่เพียงพอเมื่อคุณต้องการทราบว่าเหตุใดค่าหนึ่งจึงเป็นเช่นนั้น เพราะคุณไม่สามารถกำหนด flags แยกกันสำหรับการทดสอบแต่ละรายการได้ เมื่อผลลัพธ์จาก yabs ดูผิดปกติ ให้ทำซ้ำการทดสอบด้วย fio หรือ sysbench โดยตรง และเปลี่ยน flags ครั้งละ 1 รายการ

ตัวเลขเพียงค่าเดียวใดใช้คาดการณ์ความรู้สึกในการใช้งานแอปพลิเคชันได้

ความเร็วของ CPU แบบ single core และค่าเวลาแฝงของการอ่านแบบสุ่มขนาด 4k ตามลำดับ สำหรับงานเว็บและฐานข้อมูลส่วนใหญ่ ค่าทรูพุตดูโดดเด่น แต่แทบไม่ใช่ปัจจัยตัดสิน เนื่องจากคำขอทั่วไปมีขนาดเล็ก ให้รายงานค่าเปอร์เซ็นไทล์ที่ 99 จากบล็อก clat percentiles ของ fio แทนค่าเฉลี่ย เพราะคำขอ 1 รายการจาก 100 รายการที่ช้าคือสิ่งที่ผู้ใช้สังเกตเห็น

จำเป็นต้องติดตั้งสิ่งใดก่อนการทดสอบประสิทธิภาพหรือไม่

มี fio, sysbench และ iperf3 อยู่ในคลังแพ็กเกจของ Ubuntu และ Debian ทั้งหมด: sudo apt install -y fio sysbench iperf3 ส่วน yabs.sh ต้องใช้เพียง curl เนื่องจากจะดาวน์โหลดไบนารีแบบ static สำหรับสิ่งที่ยังไม่มี ให้ลบไฟล์ทดสอบทุกไฟล์เมื่อเสร็จสิ้น เพราะไฟล์ fio ขนาด 2G ที่ทิ้งไว้บนดิสก์ขนาด 20G อาจทำให้เกิดการแจ้งเตือนดิสก์เต็มในอีกหลายสัปดาห์ต่อมา