แก้ไขปัญหาความหน่วงในการแก้ไขร่วมกันของ ONLYOFFICE บนเซิร์ฟเวอร์ Docker ที่ติดตั้งเอง

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

คู่มือนี้ใช้ตัวอย่างสมมติตลอดทั้งเล่ม: ทีมขนาดเล็กทีมหนึ่งใช้งาน ONLYOFFICE Docs ใน Docker ที่อยู่เบื้องหลัง NGINX ผู้ใช้หนึ่งหรือสองคนสามารถแก้ไขได้ตามปกติ แต่เมื่อมีคนหกคนเปิดเอกสารเดียวกัน การอัปเดตเคอร์เซอร์จะล่าช้า และการเปลี่ยนแปลงของผู้ใช้คนอื่นจะปรากฏขึ้นหลังจากหยุดชะงักไปสักพัก ตัวอย่างนี้เป็นเพียงสถานการณ์จำลองเพื่อการสอนเท่านั้น ไม่ใช่เกณฑ์มาตรฐานหรือรายงานการใช้งานจริง

ณ เดือนตุลาคม 2026 ONLYOFFICE Docs 9.4 คือเวอร์ชันปัจจุบันที่ระบุไว้ในบันทึกการเปลี่ยนแปลงอย่างเป็นทางการ เวอร์ชัน 9.4 ยังได้เปลี่ยนแปลงสถาปัตยกรรมของ Community Edition โดยการลบการพึ่งพา RabbitMQ และฐานข้อมูล ดังนั้นคำแนะนำที่เขียนไว้สำหรับเวอร์ชันเก่าอาจไม่ตรงกับคอนเทนเนอร์ Community Edition ในปัจจุบัน โปรดตรวจสอบเวอร์ชันและรุ่นที่ติดตั้งของคุณก่อนคัดลอกคำแนะนำการปรับแต่งจากโพสต์ในฟอรัมเก่าเสมอ

1. วัดค่าความหน่วงก่อนทำการเปลี่ยนแปลงใดๆ

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

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

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

2. ตรวจสอบการใช้งาน CPU และหน่วยความจำขณะที่ผู้ใช้กำลังแก้ไข

บนโฮสต์ Docker ให้รันคำสั่ง:

docker stats

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

free -h
uptime
vmstat 1
df -h

ข้อกำหนดอย่างเป็นทางการของ ONLYOFFICE สำหรับ Docker ระบุว่าต้องมี RAM อย่างน้อย 4 GB และพื้นที่ว่างในดิสก์อย่างน้อย 40 GB สำหรับการกำหนดค่าที่ระบุไว้ในเอกสาร รวมถึงข้อกำหนดสำหรับพื้นที่ Swap ด้วย คำแนะนำสำหรับองค์กรยังระบุไว้อย่างชัดเจนว่าความจุขึ้นอยู่กับจำนวนผู้ใช้งานพร้อมกัน และจำนวน ประเภท และขนาดของเอกสาร ตัวเลขเหล่านั้นเป็นเพียงค่าพื้นฐาน ไม่ใช่การรับประกันว่า 4 GB จะช่วยให้การทำงานร่วมกันราบรื่นสำหรับทุกปริมาณงาน

ในตัวอย่างของเรา สมมติว่าdocker statsคอนเทนเนอร์ Document Server ใช้ CPU ส่วนใหญ่ที่มีอยู่ซ้ำ ๆ ทุกครั้งที่มีคนพิมพ์พร้อมกันหกคน นั่นเป็นหลักฐานที่สำคัญ: การเพิ่มการหมดเวลาของพร็อกซีจะไม่ทำให้ใช้ CPU มากขึ้น ขั้นตอนต่อไปคือการลบข้อจำกัด CPU ของ Docker ที่เข้มงวดเกินไป ย้ายคอนเทนเนอร์ไปยังโฮสต์ที่เร็วกว่า หรือลดปริมาณงานพร้อมกัน ในทางตรงกันข้าม หาก CPU ยังคงอยู่ในระดับปานกลาง ให้ตรวจสอบต่อไปก่อนที่จะซื้อฮาร์ดแวร์

เอกสารอ้างอิงอย่างเป็นทางการสำหรับคำแนะนำเกี่ยวกับความจุที่เผยแพร่คือข้อกำหนดของระบบ Docker ในเอกสาร ONLYOFFICE Docs

3. ตรวจสอบพื้นที่ดิสก์ การเมานต์ และแคชไฟล์

เอกสารประกอบการใช้งาน Docker ของ ONLYOFFICE ระบุตำแหน่งที่จัดเก็บข้อมูลถาวรไว้หลายตำแหน่ง รวมถึงตำแหน่ง/var/log/onlyofficeสำหรับบันทึกข้อมูลและ/var/lib/onlyofficeแคชไฟล์ โปรดตรวจสอบระบบไฟล์ที่รองรับเส้นทางเหล่านั้น ไม่ใช่แค่ระบบไฟล์หลักของโฮสต์เท่านั้น

df -h
docker inspect documentserver --format '{json .Mounts}'

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

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

4. ตรวจสอบว่ารีเวิร์สพร็อกซีรักษาการเชื่อมต่อแบบเรียลไทม์ไว้หรือไม่

การติดตั้ง ONLYOFFICE บนเซิร์ฟเวอร์ส่วนตัวจำนวนมากมักใช้ NGINX, Apache, HAProxy หรือ Traefik เอกสารประกอบการใช้งานพร็อกซีของ ONLYOFFICE ระบุไว้อย่างชัดเจนว่าต้องมีการส่งต่อส่วนหัว เช่น `@Proxy.hpp` X-Forwarded-ProtoและX-Forwarded-Host`@Proxy.hpp` การกำหนดค่าที่มาพร้อมกับ ONLYOFFICE ยังใช้ HTTP/1.1 และการจัดการการอัปเกรด WebSocket ด้วย

สำหรับ NGINX ให้เปรียบเทียบการตั้งค่าของคุณกับตัวอย่างอย่างเป็นทางการของ ONLYOFFICE แทนที่จะคัดลอกโค้ด WebSocket ทั่วไปจากผลิตภัณฑ์อื่น ตัวอย่างรูปแบบมีดังนี้:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Forwarded-Host $the_host;
proxy_set_header X-Forwarded-Proto $the_scheme;

คำสั่ง โดยรอบและตำแหน่งพร็อกซีที่แน่นอนmapมีความสำคัญ ใช้ตัวอย่างที่สมบูรณ์จากผู้จำหน่ายสำหรับโครงสร้างเครือข่ายของคุณ การกำหนดค่าที่รองรับมีเผยแพร่ในเอกสาร ONLYOFFICE เกี่ยวกับการใช้งานผ่านพร็อกซี

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

5. ยืนยันการเชื่อมต่อ WebSocket ในเบราว์เซอร์

เปิดเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ เลือกแผงเครือข่าย กรองหาการรับส่งข้อมูล WebSocket แล้วโหลดตัวแก้ไขใหม่ การเชื่อมต่อ WebSocket ที่สำเร็จมักจะแสดง HTTP 101 Switching Protocolsและการเชื่อมต่อที่เปิดอยู่ อย่ามองว่า WebSocket ที่แสดงสถานะ "รอดำเนินการ" เป็นเวลานานเป็นความล้มเหลว เพราะ WebSocket ที่ใช้งานอยู่ควรจะยังคงเปิดอยู่

สิ่งที่สำคัญคือพฤติกรรมการตัดการเชื่อมต่อ/เชื่อมต่อใหม่ซ้ำๆ การเชื่อมต่อล้มเหลว ข้อผิดพลาดของพร็อกซี หรือช่วงเวลาว่างที่ยาวนานซึ่งสัมพันธ์กับความล่าช้าในการทำงานร่วมกัน หากการแก้ไขระยะไกลเกิดความล่าช้าในเวลาเดียวกับการเชื่อมต่อ WebSocket ใหม่ แสดงว่าคุณมีปัญหาเครือข่ายที่ต้องแก้ไขแล้ว

ตรวจสอบการยุติ TLS, เวลาหมดอายุของพร็อกซีที่ไม่ได้ใช้งาน, กฎของโหลดบาลานเซอร์, นโยบาย WAF และตัวกลางใดๆ ที่อาจไม่รักษาการรับส่งข้อมูล WebSocket หากมีเลเยอร์พร็อกซีมากกว่าหนึ่งชั้น ให้ทดสอบแต่ละฮอปแทนที่จะสันนิษฐานว่าอินสแตนซ์ NGINX สาธารณะเป็นเพียงตัวเดียวที่เกี่ยวข้อง

6. ตรวจสอบคอนเทนเนอร์ที่คาดหวังและสถาปัตยกรรมเฉพาะรุ่น

วิ่ง:

docker compose ps
# or
docker ps

อย่าคิดว่าการติดตั้ง ONLYOFFICE รุ่นใหม่ทุกระบบจะต้องใช้ชุดคอนเทนเนอร์ Redis, PostgreSQL หรือ RabbitMQ เหมือนกันทั้งหมด เพราะเวอร์ชันมีความสำคัญ ONLYOFFICE ระบุว่า ตั้งแต่ Docs 9.4 เป็นต้นไป รุ่น Community Edition แบบโอเพนซอร์สได้รับการปรับให้เรียบง่ายขึ้นเป็นสถาปัตยกรรมแบบกระบวนการเดียว และตัดการพึ่งพา RabbitMQ และฐานข้อมูลออกไป แต่รุ่น Enterprise, Developer, รุ่น Community เก่า และชุด Compose ที่ปรับแต่งเองอาจแตกต่างกันไป

นั่นหมายความว่าบทความแก้ไขปัญหาปี 2023 ที่ระบุว่า “RabbitMQ น่าจะเป็นคอขวด” อาจไม่เกี่ยวข้องกับอินสแตนซ์ Community Edition ในปัจจุบัน ตรวจสอบให้แน่ใจว่าได้ระบุอิมเมจและเวอร์ชันที่คุณใช้งานจริง:

docker inspect documentserver --format '{.Config.Image}'
docker image ls onlyoffice/documentserver

เอกสารการเปลี่ยนแปลง อย่างเป็นทางการของ ONLYOFFICE Docsระบุเวอร์ชัน 9.4.0 พร้อมวันวางจำหน่าย 20 พฤษภาคม 2026 ประกาศการวางจำหน่าย Docs 9.4 ของผู้จำหน่าย อธิบายถึงการเปลี่ยนแปลงสถาปัตยกรรมของ Community Edition

7. เปิดใช้งานการบันทึกข้อมูลการแก้ไขข้อผิดพลาดชั่วคราวและเปรียบเทียบกับอาการหน่วง

ONLYOFFICE มีตัวแปรสภาพแวดล้อม Docker สำหรับการบันทึกข้อมูลการแก้ไขข้อผิดพลาดที่ระบุไว้ในเอกสาร หากต้องการแก้ไขปัญหาในช่วงเวลาสั้นๆ ให้เพิ่ม:

DS_LOG_LEVEL=DEBUG

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

docker logs -f documentserver
# Docker Compose:
docker compose logs -f documentserver

เอกสารอย่างเป็นทางการระบุว่า บันทึกของ Docker สามารถดูได้ทั้ง/var/log/onlyoffice/documentserverภายในคอนเทนเนอร์ และในไดเร็กทอรีบันทึกที่เชื่อมต่อกับโฮสต์ หากคุณได้ทำการเชื่อมต่อไว้ บันทึกของตัวแปลงไฟล์จะมีประโยชน์เมื่อการเปิดหรือแปลงไฟล์ช้า ในขณะที่ปัญหาการทำงานร่วมกันควรเชื่อมโยงกับบันทึกของ Document Server และการสังเกตการณ์เบราว์เซอร์/เครือข่าย

ปิดการบันทึกข้อมูลแบบละเอียด (DEBUG) หลังจากรวบรวมข้อมูลที่ต้องการเสร็จแล้ว การบันทึกข้อมูลแบบละเอียดมีไว้สำหรับการวินิจฉัยปัญหา ไม่ใช่การตั้งค่าประสิทธิภาพถาวร โปรดปฏิบัติตามขั้นตอนของผู้ผลิตในหัวข้อ "การเปิดใช้งานการบันทึกข้อมูลแบบละเอียดในเอกสาร ONLYOFFICE "

8. โปรดอัปเดตอย่างระมัดระวังหากคุณกำลังใช้ภาพเวอร์ชันเก่า

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

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

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

กรณีสมมติช่วยจำกัดขอบเขตของวิธีแก้ไขที่แท้จริงได้อย่างไร

กลับไปที่ทีมตัวอย่างที่มีบรรณาธิการร่วมหกคน ผลลัพธ์ของการแก้ไขปัญหาจะขึ้นอยู่กับสิ่งที่คุณสังเกตเห็น:

แนวทางปฏิบัติพื้นฐานสำหรับการใช้งาน Docker

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

วาง ONLYOFFICE ไว้หลังพร็อกซีแบบย้อนกลับ (reverse proxy) ที่ดัดแปลงมาจากตัวอย่างที่ผู้จำหน่ายแนะนำ โดยคงไว้ซึ่งการอัปเกรด WebSocket และส่วนหัวของโฮสต์/โปรโตคอลที่ส่งต่อ ตรวจสอบเซิร์ฟเวอร์ในระหว่างการใช้งานแก้ไขร่วมกันจริง ไม่ใช่แค่ตอนที่ไม่ได้ใช้งาน หากต้องการหลักฐานที่ละเอียดกว่านี้ ให้เปิดใช้งานการบันทึก DEBUG ชั่วคราว และเชื่อมโยงเวลาในบันทึกกับพฤติกรรม WebSocket ของเบราว์เซอร์และเมตริกของโฮสต์

สิ่งที่ไม่ควรทำ

• อย่าเปลี่ยนแปลงค่าที่ไม่ได้รับการบันทึกไว้local.jsonเพียงเพราะเห็นโพสต์ในฟอรัมบอกว่าเป็น "การปรับแต่งประสิทธิภาพ"
• อย่าเข้าใจผิดว่า WebSocket ที่แสดงสถานะ "กำลังรอการเชื่อมต่อ" นั้นเสีย การเชื่อมต่อ WebSocket ที่มีอายุการใช้งานยาวนานนั้นเป็นเรื่องปกติ
• อย่าเพิ่ม Redis, RabbitMQ หรือ PostgreSQL เพียงเพราะแผนภาพการติดตั้งใช้งานแบบเก่าใช้ระบบเหล่านั้น ตรวจสอบสถาปัตยกรรมของรุ่นและเวอร์ชันที่คุณใช้งานก่อน
• อย่าปิดใช้งานการตรวจสอบ TLS, การรักษาความปลอดภัย JWT หรือการป้องกันพร็อกซีเพื่อลดความหน่วงแฝงอย่างรวดเร็ว
• อย่านำค่าเมตริกของเซิร์ฟเวอร์ที่ไม่ได้ใช้งานมาเปรียบเทียบกับช่วงเวลาที่ผู้ใช้รายงานปัญหาความหน่วงจริง ๆ
• ห้ามอัปเกรดอินสแตนซ์ที่ใช้งานจริงโดยไม่เก็บรักษาวอลุ่ม การกำหนดค่า และเส้นทางการย้อนกลับไว้

สรุปแล้ว

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

สำหรับรายละเอียดการใช้งานในปัจจุบัน โปรดดูเอกสารการติดตั้ง ONLYOFFICE Docker , ตัวอย่าง reverse-proxy อย่างเป็นทางการ , คู่มือการบันทึกข้อมูลการแก้ไขข้อผิดพลาดและบันทึกการเปลี่ยนแปลงเอกสารอย่างเป็นทางการ