Collabora Online เทียบกับ ONLYOFFICE: การทดสอบการใช้งานทรัพยากรและเวลาแฝง

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

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

คำแนะนำอย่างเป็นทางการเกี่ยวกับแหล่งข้อมูลระบุไว้อย่างไรบ้าง

ผู้จำหน่ายเผยแพร่ข้อมูลขนาดที่เป็นประโยชน์ แต่ตัวเลขเหล่านั้นไม่เท่ากันโดยตรง คู่มือ SDK ของ Collabora มีตัวอย่างการใช้งานจริงบน Kubernetes/Helm ที่แนะนำให้ขอทรัพยากร 4 CPU และ 6 GiB หน่วยความจำ โดยมีขีดจำกัดสูงสุดที่ 8 CPU และ 8 GiB คู่มือเดียวกันนี้ยังอธิบายถึงnum_prespawn_childrenซึ่งจะทำให้กระบวนการย่อยพร้อมใช้งานอยู่เสมอ เพื่อให้เซสชันใหม่สามารถเริ่มต้นได้เร็วขึ้นโดยแลกกับหน่วยความจำที่เพิ่มขึ้น ดูคู่มือ SDK ของ Collabora Online เทมเพลตการกำหนดค่าปัจจุบันของ Collabora ยังแสดงขีดจำกัดสัดส่วนหน่วยความจำและการ ควบคุมการทำงานพร้อมกันต่อเอกสารด้วย ซอร์สโค้ดอย่างเป็นทางการของโครงการมีอยู่ในเทมเพลตการกำหนดค่า Collabora Online

ONLYOFFICE ได้เผยแพร่ข้อกำหนดระดับอ้างอิงที่ชัดเจนยิ่งขึ้นสำหรับ Docs Community Edition ใน Docker โดยคำแนะนำปัจจุบันระบุว่าควรมี RAM 4 GB ขึ้นไป และแสดงรายการการกำหนดค่าอ้างอิงดังนี้: หนึ่งคอร์ 2.8 GHz สำหรับผู้ใช้งานพร้อมกันน้อยกว่า 100 คน, สองคอร์สำหรับ 100–200 คน และสี่คอร์สำหรับ 200–400 คน โดยยังคงใช้ RAM 4 GB ในแถวอ้างอิงเหล่านั้น ผู้จำหน่ายเตือนอย่างชัดเจนว่าความจุที่แท้จริงขึ้นอยู่กับจำนวน ประเภท และขนาดของเอกสาร ดูข้อกำหนด Docker ของ ONLYOFFICE Docs Community Edition ได้ ที่นี่

เหตุใดการจับภาพหน้าจอขณะหน่วยความจำไม่ได้ใช้งานจึงไม่ถือเป็นเกณฑ์มาตรฐาน

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

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

การตั้งค่าการทดสอบทรัพยากรและความหน่วงที่เป็นธรรม

เรียกใช้ผลิตภัณฑ์ทั้งสองทีละตัวบนโฮสต์เดียวกันหรือบนเครื่องเสมือน (VM) สองเครื่องที่มีการจัดเตรียมเหมือนกันทุกประการ หลีกเลี่ยงการทดสอบตัวหนึ่งบนโฮสต์ที่อุ่นเครื่องแล้วและมีไฟล์แคชอยู่ และอีกตัวหนึ่งทันทีหลังจากบูตเครื่องเสร็จ รักษาการแจกจ่าย Linux, เวอร์ชัน Docker, โควต้า CPU, ขีดจำกัดหน่วยความจำ, คลาสพื้นที่จัดเก็บข้อมูล, พร็อกซีแบบย้อนกลับ, การยุติ TLS, เวอร์ชันเบราว์เซอร์ และเส้นทางจัดเก็บเอกสารให้เหมือนกันทุกประการ

ใช้เวิร์กโหลดเอกสารสามชุด

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

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

ทดสอบที่ระดับการทำงานพร้อมกันมากกว่าหนึ่งระดับ

ลำดับที่เหมาะสมคือ การเปิดโปรแกรมแก้ไขข้อความพร้อมกัน 1, 5, 10 และ 20 โปรแกรม ตามลำดับ จากนั้นจึงเพิ่มระดับให้สูงขึ้นเพื่อให้ตรงกับค่าสูงสุดที่คาดการณ์ไว้ “ผู้ใช้” ในแต่ละครั้งควรหมายถึงสิ่งเดียวกัน นั่นคือ แท็บโปรแกรมแก้ไขข้อความที่มีเอกสารเปิดอยู่เต็มรูปแบบ ทำซ้ำแต่ละระดับอย่างน้อยสามครั้งหลังจากทำการวอร์มอัพแล้ว และรายงานค่ามัธยฐานบวกกับผลลัพธ์ที่ช้าที่สุด วิธีนี้จะช่วยลดโอกาสที่ค่าความผันผวนเล็กน้อยในพื้นหลังจะส่งผลต่อข้อสรุป

ตัวชี้วัดทรัพยากรที่ต้องบันทึก

Docker เป็นระบบตรวจสอบข้อมูลเบื้องต้นที่ไม่ขึ้นกับผู้จำหน่ายรายใดรายหนึ่งเอกสารสถิติอย่างเป็นทางการของ Dockerอธิบายว่าdocker statsรายงานแสดงเปอร์เซ็นต์การใช้งาน CPU, การใช้งานหน่วยความจำ, การรับส่งข้อมูลเครือข่าย, การรับส่งข้อมูลบล็อก และ PID สามารถบันทึกทั้งสตรีมสดระหว่างการทำงานและตัวอย่างที่ไม่สตรีม ณ จุดตรวจสอบที่กำหนดไว้ได้

docker stats collabora --no-stream
docker stats onlyoffice --no-stream

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

อย่าเปรียบเทียบเฉพาะเปอร์เซ็นต์ของคอนเทนเนอร์ หากคอนเทนเนอร์หนึ่งมีข้อจำกัดด้าน CPU หรือหน่วยความจำที่แตกต่างกัน ให้บันทึกข้อจำกัดของโฮสต์หรือ cgroup จริงไว้กับผลการทดสอบประสิทธิภาพ ตัวเลขหน่วยความจำของ Docker บน Linux ยังมีรายละเอียดปลีกย่อยเกี่ยวกับการนับแคช ดังนั้นควรใช้สภาพแวดล้อม Docker และ cgroup เดียวกันสำหรับทั้งสองผลิตภัณฑ์

วิธีการวัดค่าความหน่วงในการเปิดไฟล์

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

เก็บข้อมูลความหน่วงในการเปิดไฟล์สองรูปแบบ การเปิดแบบเย็น (Cold open ) เริ่มต้นหลังจากรีสตาร์ทคอนเทนเนอร์ Office และล้างเซสชันการทดสอบการเปิดแบบอุ่น (Warm open)คือการเปิดไฟล์เดิมซ้ำโดยไม่ต้องรีสตาร์ทบริการ การตั้งค่า prespawn ของ Collabora ทำให้ความแตกต่างนี้มีความสำคัญเป็นพิเศษ เนื่องจากกระบวนการลูกที่รออยู่มากขึ้นสามารถลดความล่าช้าในการเริ่มต้นได้ แต่ในขณะเดียวกันก็เพิ่มการใช้หน่วยความจำ หากคุณปรับแต่งค่าnum_prespawn_childrenให้แสดงค่าดังกล่าวควบคู่ไปกับผลลัพธ์แทนที่จะซ่อนไว้

วิธีการวัดความล่าช้าในการทำงานร่วมกัน

สำหรับการแก้ไขร่วมกันแบบเรียลไทม์ ตัวชี้วัดที่มีความหมายไม่ใช่การวัดค่า ICMP ping ทั่วไป ให้วัดความล่าช้าระหว่างการแก้ไขในเบราว์เซอร์ A กับการเปลี่ยนแปลงที่มองเห็นได้ในเบราว์เซอร์ B ใช้โปรไฟล์เบราว์เซอร์หรือเครื่องคอมพิวเตอร์สองเครื่องที่แยกจากกัน และซิงโครไนซ์นาฬิกาของทั้งสองเครื่อง บันทึกการแก้ไขง่ายๆ 20-50 ครั้ง เช่น การเพิ่มตัวอักษรลงในย่อหน้าเดียวกัน จากนั้นคำนวณค่ามัธยฐานและค่าเปอร์เซ็นไทล์ที่ 95 ของความล่าช้าในการแสดงผล

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

เพิ่มการหน่วงเวลาเครือข่ายแบบควบคุม

หากผู้ใช้ของคุณอยู่ห่างไกล ให้ทำการทดสอบการทำงานร่วมกันซ้ำโดยควบคุมค่าความหน่วงเวลาในการรับส่งข้อมูลไป-กลับ เช่น ประมาณ 20 มิลลิวินาที 80 มิลลิวินาที และ 150 มิลลิวินาที ใช้การปรับแต่งเครือข่ายแบบเดียวกันกับทั้งสองระบบและบันทึกรายละเอียดว่าเริ่มใช้การปรับแต่งที่ใด การทำเช่นนี้จะเผยให้เห็นความแตกต่างที่การทดสอบประสิทธิภาพในเครือข่าย LAN เดียวกันอาจซ่อนไว้: บรรณาธิการอาจรู้สึกว่าการทำงานราบรื่นดีเยี่ยมที่ค่า RTT 1-5 มิลลิวินาที แต่จะรู้สึกว่าการทำงานรวดเร็วน้อยลงอย่างเห็นได้ชัดสำหรับสำนักงานสาขาหรือทีมงานต่างประเทศ

เวลาในการบันทึกข้อมูลจำเป็นต้องมีการวัดค่าเฉพาะของตัวเอง

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

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

เอกสารสรุปผล: ตัวเลขที่สำคัญ

วิธีตีความผลลัพธ์

หาก Collabora ใช้หน่วยความจำที่ไม่ได้ใช้งานในระบบของคุณมากกว่า แต่ทำให้เวลาในการเปิดเอกสารครั้งแรก (cold-open latency) น้อยลง นั่นอาจเป็นการแลกเปลี่ยนที่ยอมรับได้หากผู้ใช้เปิดเอกสารบ่อยครั้งและเซิร์ฟเวอร์มี RAM เหลือเฟือ ในทางกลับกัน หาก ONLYOFFICE แสดงค่าพื้นฐานที่ต่ำกว่า แต่มีการใช้งาน CPU สูงขึ้นอย่างมากในระหว่างการแปลงไฟล์ แสดงว่า CPU ที่เหลือเฟืออาจมีความสำคัญมากกว่าหน่วยความจำ รูปแบบตรงกันข้ามก็เป็นไปได้เช่นกัน ประเด็นสำคัญคือการเชื่อมโยงเส้นโค้งทรัพยากรแต่ละเส้นเข้ากับเหตุการณ์ที่ผู้ใช้มองเห็นได้

สำหรับการติดตั้งใช้งานบนเซิร์ฟเวอร์ส่วนตัวขนาดเล็ก ให้เน้นที่การใช้ทรัพยากรขณะไม่ได้ใช้งาน เวลาเปิดไฟล์ครั้งแรก และว่าเอกสารขนาดใหญ่หนึ่งหรือสองฉบับทำให้เกิดการสลับหน่วยความจำหรือไม่ สำหรับการใช้งานในองค์กรที่มีผู้แก้ไขหลายสิบคน ให้ให้ความสำคัญกับอัตราการเพิ่มขึ้นของหน่วยความจำ ความอิ่มตัวของ CPU ความล่าช้าในการแก้ไขร่วมกัน (p95) และการฟื้นตัวหลังจากโหลด สำหรับผู้ใช้งานที่กระจายอยู่ตามภูมิศาสตร์ต่างๆ ค่า RTT ของเครือข่ายและการกำหนดค่าพร็อกซีอาจมีความสำคัญมากกว่าความแตกต่างเล็กน้อยในฝั่งเซิร์ฟเวอร์

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