วิธีทำ Benchmark บน VPS ให้แม่นยำและอ่านค่าเป็น

ความหมายของการทำ Benchmark บน VPS

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

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

ตรวจสอบเครื่องก่อนทำการวัดผล

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

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

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

cat /sys/fs/cgroup/cpu.max

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

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

เฝ้าสังเกตค่า steal time ตลอดเวลา

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

vmstat 1 10

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

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

yabs.sh (Yet Another Bench Script) เป็นเชลล์สคริปต์ที่ดาวน์โหลดไฟล์ binary แบบ static ของ fio, iperf3 และ Geekbench มาประมวลผลและแสดงสรุปผลลัพธ์ในที่เดียว นี่เป็นภาษามาตรฐานที่ใช้ในการสนทนาเรื่องผลทดสอบ VPS ดังนั้นผลลัพธ์จาก yabs จึงเป็นวิธีที่รวดเร็วที่สุดในการเปรียบเทียบประสิทธิภาพกับผู้อื่น

คำสั่งแบบบรรทัดเดียวของโปรเจกต์นี้คือ

curl -sL yabs.sh | bash

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

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

สามารถใส่ flag ต่อท้าย -s -- ได้หากใช้วิธี pipe หรือใส่ต่อท้ายชื่อไฟล์โดยตรงเมื่อรันไฟล์ที่ดาวน์โหลดมาแล้ว flag ที่มีประโยชน์ได้แก่ -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

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

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

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

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

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

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

การทดสอบการอ่านแบบสุ่มขนาด 4k ที่ queue depth 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 ออกมา ค่า percentile ที่ 99.00th คือตัวเลขที่ควรนำมาอ้างอิง เพราะเป็นระยะเวลาที่คำขอที่ช้าที่สุด 1 รายการใน 100 รายการต้องรอ ค่าเฉลี่ย (average latency) มักจะบดบังอาการกระตุกที่ผู้ใช้งานสัมผัสได้จริง

• --direct=1 เปิดไฟล์ด้วย O_DIRECT เพื่อให้การอ่านข้าม kernel page cache ไป หากไม่มี flag นี้ การทดสอบรอบที่สองบนไฟล์ขนาด 2G ในเครื่องที่มี RAM 8G จะถูกอ่านจากหน่วยความจำ และ fio จะรายงานค่า IOPS ในระดับล้าน ซึ่งตัวเลขนั้นเป็นจริง แต่เป็นตัวเลขของหน่วยความจำไม่ใช่ดิสก์
• --ioengine=libaio ส่งคำขอแบบอะซิงโครนัส ซึ่งเป็นสิ่งที่ทำให้ --iodepth=32 สามารถคงจำนวนคำขอที่ค้างอยู่ (in flight) ไว้ได้ 32 รายการ หากใช้ engine แบบซิงโครนัสอย่าง psync ค่า iodepth ที่มากกว่า 1 จะไม่มีผลใดๆ ทำให้คุณวัดได้เพียงทีละหนึ่งคำขอเท่านั้น
• --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

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

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

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

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

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

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

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

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

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

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

เครือข่าย: iperf3

วิธีที่ตรงไปตรงมาที่สุดในการทดสอบปริมาณข้อมูล (throughput) คือการทดสอบกับเครื่องอีกเครื่องที่คุณควบคุมได้ เพราะคุณจะทราบสถานะการทำงานของทั้งสองฝั่ง

ที่ฝั่งปลายทาง:

iperf3 -s

คำสั่งนี้จะเปิดการรับฟังที่ TCP พอร์ต 5201 ให้เปิดพอร์ตนี้เฉพาะสำหรับที่อยู่ IP ที่คุณใช้ทดสอบเท่านั้น และปิดพอร์ตทันทีเมื่อเสร็จสิ้น กฎพื้นฐานของ ufw firewall บน 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 หนึ่งรายการสามารถรองรับข้อมูลที่ยังไม่ได้รับการตอบรับ (unacknowledged data) ได้จำกัดตามขนาดของหน้าต่าง (window size) ดังนั้นขีดจำกัดจึงอยู่ที่ขนาดหน้าต่างหารด้วยเวลาในการรับส่งข้อมูลไปกลับ (round trip time) หากมีความหน่วง (latency) ที่ 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 สำหรับ Network attached block storage ซึ่งทุกคำขอต้องผ่านเครือข่ายก่อนจะถึงดิสก์ ค่าจะอยู่ที่ประมาณ 12,000 และสำหรับฮาร์ดดิสก์แบบจานหมุนจะทำได้ที่ประมาณ 180 เนื่องจากต้องมีการเคลื่อนที่ของหัวอ่านจริงสำหรับทุกคำขอแบบสุ่ม

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

เหตุใดการทดสอบเพียงครั้งเดียวจึงไม่ใช่การทำ benchmark

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

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

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

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

เครื่องมือสังเคราะห์ (Synthetic tools) จัดอันดับเครื่องเซิร์ฟเวอร์ได้เพียงเบื้องต้นเท่านั้น มีเพียงภาระงานของคุณเองเท่านั้นที่จะบอกได้ว่าเครื่องนั้นเพียงพอหรือไม่ ให้จับเวลาสิ่งที่คุณทำจริง

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

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

FAQ

ทำไมผลการทดสอบ benchmark ถึงไม่เท่ากันในแต่ละครั้งที่รัน?

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

ทำไม fio ถึงรายงานค่า IOPS สูงถึงหลักล้าน?

เกือบทุกกรณีเกิดจากการลืมใส่ --direct=1 หากไม่มีแฟล็กนี้ fio จะอ่านผ่าน kernel 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 ที่ขนาดบล็อก 4 แบบ, iperf3 ทั้งสองทิศทาง และ Geekbench พร้อมสรุปผลในรูปแบบที่ผู้อื่นอ่านเข้าใจง่าย แต่จะไม่เพียงพอเมื่อคุณต้องการทราบสาเหตุของตัวเลขนั้นๆ เพราะคุณไม่สามารถปรับเปลี่ยนแฟล็กแยกรายรายการได้ เมื่อผลลัพธ์จาก yabs ดูผิดปกติ ให้ทดสอบซ้ำด้วย fio หรือ sysbench โดยตรงและปรับเปลี่ยนทีละแฟล็ก

ตัวเลขใดที่บ่งบอกถึงประสิทธิภาพการใช้งานจริงของแอปพลิเคชันได้ดีที่สุด?

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

จำเป็นต้องติดตั้งอะไรก่อนทำ benchmark หรือไม่?

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