Ubuntu Server 24.04 รุ่น Minimal เทียบกับรุ่น Standard: คำอธิบายเกี่ยวกับเกณฑ์วัดประสิทธิภาพ

เซิร์ฟเวอร์ส่วนตัวเสมือน (VPN) รู้สึกว่าหน่วยความจำเหลือน้อย คุณจึงติดตั้ง Ubuntu Server 24.04 LTS ใหม่ และต้องเผชิญกับตัวเลือกแรกๆ คือ การติดตั้ง Ubuntu Server แบบปกติ หรือ Ubuntu Server (แบบย่อขนาด) หลายคนอาจคิดว่าจำนวนแพ็กเกจที่น้อยลงจะทำให้การร้องขอเว็บเร็วขึ้น การสืบค้นฐานข้อมูลสั้นลง และการประมวลผล CPU สูงขึ้น แต่ความจริงแล้วความแตกต่างนั้นซับซ้อนกว่านั้น ชุดแพ็กเกจเริ่มต้นที่เล็กกว่าจะช่วยลดการใช้งานดิสก์และกิจกรรมเบื้องหลังได้ แต่ไม่ได้หมายความว่าโปรเซสเซอร์หรืออุปกรณ์จัดเก็บข้อมูลจะเร็วขึ้นโดยอัตโนมัติ

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

หมายเหตุหลักฐาน (9 ตุลาคม 2026):บทความนี้อธิบายวิธีการวัดประสิทธิภาพที่สามารถทำซ้ำได้ และผลลัพธ์ที่แต่ละตัวชี้วัดสามารถสร้างขึ้นได้ บทความนี้ไม่ได้นำเสนอคะแนนที่วัดได้จริงจากระบบ Ubuntu 24.04 สองระบบที่จับคู่กัน และไม่มีการนำเสนอตัวเลข RAM, ดิสก์, เวลาบูต หรือปริมาณงานที่ยังไม่ได้รับการตรวจสอบเป็นผลการทดสอบ

Ubuntu Server รุ่นมาตรฐานกับรุ่นย่อส่วนต่างกันอย่างไร?

โปรแกรมติดตั้ง Subiquity ของ Ubuntu Server มีแหล่งติดตั้งสองแบบ: ubuntu-serverแบบมาตรฐาน (ค่าเริ่มต้น) และubuntu-server-minimalแบบย่อขนาด Canonical ได้จัดทำเอกสารเกี่ยวกับตัวระบุแหล่งติดตั้งเหล่านี้และแนะนำให้ตรวจสอบcasper/install-sources.yamlในไฟล์ ISO ที่เลือก เนื่องจากตัวระบุโปรแกรมติดตั้งอาจเปลี่ยนแปลงได้ โปรดดู เอกสารประกอบแหล่งติดตั้งอัตโนมัติ ของCanonical Subiquity

ทั้งสองอย่างคือ Ubuntu Server 24.04 LTS ไม่ใช่สถาปัตยกรรม CPU ที่ปรับแต่งแตกต่างกัน หรือระบบปฏิบัติการ Linux ที่แยกจากกัน สิ่งที่เปลี่ยนแปลงหลักๆ คือซอฟต์แวร์ที่มาพร้อมกับการติดตั้ง แพ็กเกจที่ปรากฏจะขึ้นอยู่กับเวอร์ชันของสื่อการติดตั้ง ตัวเลือกเพิ่มเติม การอัปเดต ไดรเวอร์ และแอปพลิเคชันที่ติดตั้งในภายหลัง อย่าคิดว่ารายการที่เผยแพร่สำหรับอิมเมจเวอร์ชันหนึ่งจะใช้ได้กับตัวติดตั้ง 24.04 รุ่นต่างๆ ทุกตัวโดยไม่เปลี่ยนแปลง

ตัวเลือกเซิร์ฟเวอร์แบบย่อส่วนไม่ควรสับสนกับอิมเมจคลาวด์ Ubuntu แบบย่อส่วน ซึ่งเป็นตระกูลอิมเมจที่แยกต่างหาก หรือกับตัวเลือกการติดตั้ง Ubuntu Desktop แบบย่อส่วนบันทึกการเผยแพร่ Ubuntu 24.04 LTSกล่าวถึงการลดจำนวนแพ็กเกจและขนาดไฟล์ดาวน์โหลดของอิมเมจคลาวด์ แบบย่อส่วนลงอย่างมาก เมื่อเทียบกับเวอร์ชันก่อนหน้า ตัวอย่างอิมเมจคลาวด์ที่เผยแพร่เหล่านั้นไม่ใช่เกณฑ์มาตรฐานเปรียบเทียบระหว่างมาตรฐานกับ ISO เซิร์ฟเวอร์แบบสดที่ย่อส่วน และไม่ควรนำตัวเลขเหล่านั้นมาใช้ซ้ำราวกับว่าเป็นเช่นนั้น

เกณฑ์วัดประสิทธิภาพใดบ้างที่สำคัญ?

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

เริ่มต้นด้วยการตั้งค่าการทดสอบที่เป็นธรรม ไม่ใช่การใช้เครื่องจับเวลา

สร้างเครื่องเสมือนแบบใช้แล้วทิ้งสองเครื่องจากไฟล์ ISO ของ Ubuntu Server 24.04 LTS เวอร์ชันเดียวกัน เครื่องหนึ่งเป็นแบบมาตรฐานและอีกเครื่องเป็นแบบย่อขนาด กำหนดจำนวน vCPU, RAM, ดิสก์เสมือน, ระบบไฟล์, โหมดบูต, การตั้งค่าไฮเปอร์ไวเซอร์, การเชื่อมต่อเครือข่าย และคลาสการจัดเก็บข้อมูลให้เหมือนกัน สำหรับเครื่องจริง ให้ใช้ฮาร์ดแวร์ที่เทียบเท่ากันและทดสอบภายใต้สภาวะความร้อนและพลังงานที่คล้ายคลึงกัน อย่าใช้งานเครื่องเหล่านี้ในสภาพแวดล้อมการใช้งานจริง

บนทั้งสองระบบ ให้ทำการอัปเดตความปลอดภัยเดียวกันแล้วรีบูต บันทึกcat /etc/os-release, uname -r, และlscpuรวมถึงเวอร์ชันของอิมเมจตัวติดตั้งและวันที่ทดสอบ Ubuntu Server 24.04 โดยปกติจะใช้เคอร์เนลเวอร์ชันทั่วไป (General-Availability Kernel Track) แต่สามารถใช้เคอร์เนลเวอร์ชันสำหรับการเปิดใช้งานฮาร์ดแวร์ (Hardware Enablement Kernel หรือ HWE Kernel) ได้ หากใช้เคอร์เนลเวอร์ชันที่แตกต่างกัน จะทำให้การเปรียบเทียบเฉพาะประเภทการติดตั้งทำได้ยากเอกสารประกอบเคอร์เนลของ Ubuntu เกี่ยวกับ GA และ HWE Kernelจะอธิบายความแตกต่างนี้

ทำการวัดสองชุด:

1. เกณฑ์มาตรฐานการติดตั้งใหม่:ทันทีหลังจากอัปเดตที่เหมือนกันทุกประการ ก่อนที่จะติดตั้งเวิร์กโหลด เพื่อแยกความแตกต่างในทางปฏิบัติของค่าเริ่มต้นในการติดตั้ง
2. เกณฑ์มาตรฐานที่เหมือนกับการใช้งานจริง:หลังจากติดตั้งแพ็กเกจแอปพลิเคชันเดียวกัน เปิดใช้งานบริการเดียวกัน และใช้การกำหนดค่าที่เหมือนกันทุกประการแล้ว ขั้นตอนนี้จะแสดงให้เห็นว่าความแตกต่างของขนาดไฟล์เริ่มต้นยังคงมีความสำคัญอยู่หรือไม่

ควรทำการทดสอบอย่างน้อยหลายครั้ง โดยควรทดสอบห้าครั้งขึ้นไปหลังจากวอร์มเครื่องแล้ว และเปรียบเทียบค่ามัธยฐานรวมถึงค่าความแปรปรวน รีบูตเครื่องและวัดเวลาบูตเครื่องในหลายๆ ครั้ง ห้ามเปรียบเทียบผลลัพธ์การบูตเครื่องเย็นบนระบบหนึ่งกับผลลัพธ์การบูตเครื่องอุ่นแล้วบนอีกระบบหนึ่งเด็ดขาด

วัดความแตกต่างที่เห็นได้ชัดก่อน

1. นับจำนวนแพ็กเกจที่ติดตั้งและตรวจสอบพื้นที่ว่างในดิสก์

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

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

บันทึกจำนวนพาร์ติชั่น พื้นที่ที่ใช้ไปในระบบไฟล์หลัก และโครงสร้างของระบบไฟล์ ตรวจสอบให้แน่ใจว่าพาร์ติชั่นหลักมีขนาดใกล้เคียงกัน มิเช่นนั้น ความแตกต่างที่เห็นได้ชัดอาจเกิดจากการแบ่งพาร์ติชั่น การใช้งานดิสก์ยังรวมถึงบันทึกข้อมูล แคชแพ็กเกจ และข้อมูลเมตาของระบบไฟล์ ดังนั้นเวลาในการติดตั้งที่เท่ากันและประวัติการอัปเดตที่เทียบเคียงกันได้จึงมีความสำคัญ

2. เปรียบเทียบ RAM ที่ใช้งานได้ ไม่ใช่แค่ RAM ที่ "ว่างอยู่"

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

free -h
systemctl --type=service --state=running --no-pager

ดูที่availableคอลัมน์นั้นด้วยfreeเช่นกันusedLinux ใช้หน่วยความจำที่ไม่ได้ใช้งานสำหรับแคช ซึ่งสามารถเรียกคืนได้เมื่อแอปพลิเคชันต้องการใช้งาน ค่าที่น้อยลงในfreeคอลัมน์นั้นไม่ได้หมายความว่ามีปัญหาเสมอไป ตรวจสอบว่าการใช้หน่วยความจำเพิ่มเติมนั้นเป็นของบริการที่คุณวางแผนจะใช้งานต่อไปหรือไม่

3. เปรียบเทียบเวลาในการบูตเครื่องและค้นหาบริการที่ทำงานช้า

ทุกครั้งที่บูตเครื่อง ให้ใช้เครื่องมือ systemd ที่มาพร้อมกับการแจกจ่ายระบบปฏิบัติการ:

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

systemd-analyze timeรายงานแสดงเวลาการบูตระบบ แต่ไม่ได้หมายความว่าแอปblameพลิเคชันพร้อมรับคำขอเสมอไป รายการดังกล่าวยังอาจทำให้เข้าใจผิดได้ เนื่องจากหน่วยต่างๆ อาจเริ่มต้นทำงานพร้อมกัน และบริการบางประเภทก็ไม่ได้วัดผลในลักษณะเดียวกัน ตรวจสอบห่วงโซ่การทำงานที่สำคัญก่อน จากนั้นตรวจสอบปลายทางบริการที่คุณสนใจโดยเฉพาะแยกต่างหาก ข้อจำกัดเหล่านี้มีบันทึกไว้ในคู่มือ systemd-analyze ของ Ubuntu 24.04

ตัวอย่างเช่น หากเซิร์ฟเวอร์รัน API ผ่าน HTTP ให้วัดเวลาตั้งแต่เริ่มรีบูตจนกระทั่งการตรวจสอบสถานะของ API สำเร็จ หากโฮสต์รันฐานข้อมูล ให้ตรวจสอบว่าการสืบค้นข้อมูลสำเร็จ การวัดความพร้อมใช้งานดังกล่าวมีประโยชน์มากกว่าการที่ระบบปฏิบัติการสามารถบูตได้ตามเป้าหมาย

จากนั้นทดสอบ CPU และอุปกรณ์จัดเก็บข้อมูลภายใต้ภาระการทำงานที่ควบคุมได้

4. รันภาระงาน CPU เดียวกันบนเครื่องทั้งสองเครื่อง

สำหรับการเปรียบเทียบ CPU อย่างง่าย ให้ติดตั้ง sysbench เวอร์ชันเดียวกันบน VM ชั่วคราวแต่ละเครื่องหลังจากบันทึกขนาดไฟล์หลังการติดตั้งใหม่ จากนั้นเรียกใช้คำสั่งเดียวกัน:

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

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

5. ทดสอบการรับส่งข้อมูลดิสก์โดยไม่ต้องทำการวัดประสิทธิภาพดิสก์ที่ใช้งานจริง

สำหรับการทดลองเกี่ยวกับการจัดเก็บข้อมูล (ซึ่งเป็นทางเลือก) ให้ติดตั้ง fio บนเครื่องทดสอบทั้งสองเครื่อง และสร้างไฟล์ทดสอบที่เหมือนกันบนระบบไฟล์แบบใช้แล้วทิ้งที่มีพื้นที่ว่างเหลือเฟือ คำสั่งต่อไปนี้จะสร้างไฟล์ขนาด 256 MiB ในไดเร็กทอรีโฮมของผู้ใช้ปัจจุบัน จากนั้นเรียกใช้เวิร์กโหลดการอ่านแบบสุ่มที่มีขอบเขตจำกัดกับไฟล์นั้น:

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

รันเครื่องทั้งสองเครื่องด้วยดิสก์และพารามิเตอร์ I/O ที่เหมือนกัน ไฟล์ขนาด 256 MiB อาจเล็กเกินไปที่จะจำลองฐานข้อมูลหรืออุปกรณ์จัดเก็บข้อมูลของคุณได้อย่างแม่นยำ ขยายขนาดไฟล์และปรับเปลี่ยนปริมาณงานเฉพาะเมื่อมีพื้นที่ชั่วคราวเพียงพอและสภาพแวดล้อมการทดสอบที่ปลอดภัยเท่านั้น บันทึก IOPS แบนด์วิดท์ และการกระจายความหน่วง ไม่ใช่แค่ตัวเลขแบนด์วิดท์สูงสุดคู่มือ Ubuntu 24.04 fioอธิบายพารามิเตอร์ปริมาณงาน อย่าทำการทดสอบการเขียนไปยังอุปกรณ์บล็อกดิบที่มีข้อมูลที่มีประโยชน์อยู่

6. ทดสอบการใช้งานจริงเป็นขั้นตอนสุดท้าย

ติดตั้งชุดแอปพลิเคชันเดียวกันทุกประการบนเครื่องทั้งสองเครื่อง รวมถึงเวอร์ชันเว็บหรือฐานข้อมูล ข้อจำกัดการเชื่อมต่อ การบันทึกข้อมูล TLS การแคช และการตรวจสอบ ส่งคำขอผสมที่เทียบเท่ากันจากตัวสร้างโหลดแยกต่างหาก โดยมีการทำงานพร้อมกันและระยะเวลาทดสอบเท่ากัน วัดปริมาณงาน ความหน่วงในการตอบสนองเฉลี่ยและเปอร์เซ็นไทล์ที่ 95 อัตราข้อผิดพลาด การใช้งาน CPU แรงดันหน่วยความจำ และการสลับข้อมูล ใช้ชุดข้อมูลเดียวกัน และตรวจสอบให้แน่ใจว่าไม่มีเครื่องใดใช้ระบบจัดเก็บข้อมูลที่มีสัญญาณรบกวนร่วมกันโดยไม่คำนึงถึงการแย่งชิงทรัพยากร

สำหรับเซิร์ฟเวอร์ API ขนาดเล็ก ความแตกต่างของหน่วยความจำที่ไม่ได้ใช้งานนั้นมีความสำคัญ หากการกำหนดค่าหนึ่งเริ่มสลับหน่วยความจำระหว่างการโหลด สำหรับเวิร์กเกอร์ที่ใช้ CPU เป็นหลักและมี RAM เหลือเฟือ ไบนารีของแอปพลิเคชันที่เหมือนกันอาจให้ปริมาณงานที่ใกล้เคียงกัน ผลลัพธ์ใดๆ ก็ไม่สามารถยืนยันได้ก่อนการทดสอบ

วิธีตีความผลลัพธ์มาตรฐานที่ขัดแย้งกัน

• จำนวนแพ็กเกจน้อยลง แต่คะแนน CPU เท่าเดิม:นี่เป็นไปตามหลักการอย่างสมบูรณ์ การติดตั้งเครื่องมือจำนวนน้อยลงไม่จำเป็นต้องทำให้ประสิทธิภาพการประมวลผลเปลี่ยนแปลงไป
• ลดการใช้ดิสก์ แต่ยังคงประสิทธิภาพ IOPS เท่าเดิม:พื้นที่ว่างและความเร็วของอุปกรณ์เป็นคุณสมบัติที่แตกต่างกัน พิจารณาฮาร์ดแวร์จัดเก็บข้อมูล รูปแบบ I/O ระบบไฟล์ และแคช
• การบูตระบบด้วย systemd เร็วขึ้น แต่ความพร้อมของแอปพลิเคชันกลับช้าลง:ปัญหาคอขวดอาจอยู่ที่การเริ่มต้นแอปพลิเคชัน การพึ่งพาเครือข่าย หรือการกู้คืนฐานข้อมูล
• หน่วยความจำที่ไม่ได้ใช้งานน้อยลง แต่ความหน่วงในการร้องขอเท่าเดิม:การลดขนาดหน่วยความจำอาจช่วยเพิ่มพื้นที่ว่างในการใช้งานได้ แต่ภาระงานปัจจุบันไม่ได้จำกัดด้วยหน่วยความจำ
• คะแนนที่เปลี่ยนแปลงอย่างมากระหว่างการทดสอบแต่ละครั้ง:ตรวจสอบปัจจัยรบกวนต่างๆ เช่น เครื่องข้างเคียง การปรับความถี่ CPU การอัปเดต งานที่กำหนดเวลาไว้ การลดประสิทธิภาพเนื่องจากความร้อน และการอุ่นแคช ก่อนที่จะประกาศผู้ชนะ

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

คุณควรเปลี่ยนเซิร์ฟเวอร์ที่มีอยู่ให้เป็นโหมดมินิมิกหรือไม่?

โดยปกติแล้ว การลบแพ็กเกจไม่ได้ทำไปเพื่อไล่ล่าตัวเลขประสิทธิภาพเพียงอย่างเดียว สำหรับการติดตั้งมาตรฐานที่ใช้งานได้จริง ควรตรวจสอบบริการที่ใช้งานอยู่จริงและวัดประสิทธิภาพของแอปพลิเคชันก่อน การลบแพ็กเกจที่ไม่เกี่ยวข้องอาจไม่ได้ช่วยปรับปรุงประสิทธิภาพการทำงานที่ดีอยู่แล้ว และการลบแพ็กเกจอย่างไม่ระมัดระวังอาจทำให้ระบบเครือข่าย การกู้คืน การบันทึก หรือการจัดการระยะไกลเสียหายได้คำแนะนำด้านความปลอดภัยของ Ubuntu จาก Canonical เกี่ยวกับแพ็กเกจที่ไม่จำเป็น แนะนำให้เลือกการติดตั้งเริ่มต้นที่เหมาะสมและมีขนาดเล็กที่สุด แทนที่จะลบแพ็กเกจเริ่มต้นโดยไม่เลือกปฏิบัติ

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

เรื่องความปลอดภัยนั้นเกี่ยวข้องกันแต่ก็แยกจากกัน: การลดจำนวนแพ็กเกจซอฟต์แวร์อาจช่วยลดปริมาณซอฟต์แวร์ที่คุณต้องดูแลรักษา แต่สิ่งนี้ไม่ได้เป็นหลักฐานยืนยันว่ามีการลดช่องโหว่ความปลอดภัย (CVE) ลงแต่อย่างใด ทั้งสองประเภทของการติดตั้งยังคงต้องการการอัปเดตด้านความปลอดภัยและการเสริมความแข็งแกร่งของบริการอยู่ดี

รายการตรวจสอบการตรวจสอบขั้นสุดท้าย

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

สรุปในทางปฏิบัติ:โดยทั่วไปแล้ว โหมด Minimized มีขนาดเริ่มต้น ที่ดีกว่า สำหรับเซิร์ฟเวอร์อัตโนมัติที่มีขอบเขตการใช้งานจำกัด ในขณะที่โหมด Standard มีชุดเครื่องมือเริ่มต้นที่ครบครันกว่า ไม่มีตัวเลือกใดเร็วกว่ากันเสมอไป บน Ubuntu Server 24.04 LTS เกณฑ์วัดประสิทธิภาพที่มีประโยชน์ที่สุดคือเกณฑ์ที่วัดประสิทธิภาพของบริการภายใต้ภาระงานที่ต้องจัดการจริง