แก้ปัญหาความล่าช้าในการแก้ไขร่วมของ ONLYOFFICE ด้วยการค้นหาจุดที่เป็นปัญหา

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

1. จำลองอาการแล็กและตรวจสอบเซิร์ฟเวอร์ก่อนปรับแต่ง

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

บนโฮสต์ Docker ให้ระบุคอนเทนเนอร์ Document Server และสังเกตการใช้งานทรัพยากรขณะที่เกิดอาการหน่วง:

docker ps
 docker stats <container_name_or_id>

สังเกตการใช้งาน CPU ที่ต่อเนื่องจนเต็มความจุ หน่วยความจำใกล้ถึงขีดจำกัดของโฮสต์หรือคอนเทนเนอร์ การทำงานของสวอป หรือคอนเทนเนอร์ที่รีสตาร์ท นอกจากนี้ ให้ตรวจสอบพื้นที่ดิสก์ของโฮสต์และ I/O หากการบันทึกหรือการโหลดเอกสารหยุดชะงัก การใช้งานที่พุ่งสูงขึ้นในช่วงสั้นๆ นั้นไม่ชัดเจนเท่ากับปัญหาคอขวดที่เกิดขึ้นพร้อมกับการแก้ไขที่ช้าลงหน้าการแก้ไขปัญหาของ ONLYOFFICE Dockerระบุว่าการใช้หน่วยความจำจะเพิ่มขึ้นตามจำนวนเอกสารที่เปิดและผู้ใช้พร้อมกัน โดยระบุว่าปกติแล้วควรใช้หน่วยความจำ 2-4 GB สำหรับเซิร์ฟเวอร์ที่มีผู้ใช้ใช้งานอยู่ไม่กี่สิบคน แต่ขนาดดังกล่าวไม่ใช่การรับประกันเสมอไป

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

2. หากบรรณาธิการเชื่อมต่อใหม่ โปรดตรวจสอบพร็อกซีและเส้นทางเครือข่าย

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

ตรวจสอบบันทึกการเข้าถึงและข้อผิดพลาดของพร็อกซีระหว่างเซสชันที่มีความล่าช้า ตรวจสอบให้แน่ใจว่าการกำหนดค่าของคุณส่งต่อส่วนหัว HTTP Upgrade และ Connection และรักษาโฮสต์และโปรโตคอลเดิมไว้ สำหรับ NGINX ให้เปรียบเทียบการตั้งค่าของคุณกับตัวอย่างพร็อกซีอย่างเป็นทางการ ของ ONLYOFFICE เอกสารระบุถึงส่วนหัวที่ส่งต่อไว้อย่างชัดเจนX-Forwarded-Protoอย่าX-Forwarded-Hostคัดลอกตัวอย่างทั้งหมดหากการยุติ TLS, คำนำหน้าเส้นทาง หรือโทโพโลยีพร็อกซีของคุณแตกต่างกัน

ทดสอบจากไคลเอนต์บนเครือข่าย LAN เดียวกัน และจากเส้นทางการเข้าถึงระยะไกลปกติด้วย หากการเชื่อมต่อ LAN ตอบสนองได้ดีในขณะที่เส้นทางสาธารณะช้า ให้ตรวจสอบพร็อกซี ไฟร์วอลล์ VPN DNS หรือความหน่วงของ WAN หากทั้งสองเส้นทางช้าพร้อมกัน แสดงว่าอาจมีปัญหาเรื่องภาระงานฝั่งเซิร์ฟเวอร์ เครื่องมือสำหรับนักพัฒนาเบราว์เซอร์สามารถช่วยได้: การตัดการเชื่อมต่อ WebSocket ซ้ำๆ ชี้ไปที่การจัดการการเชื่อมต่อ ในขณะที่การเชื่อมต่อที่เสถียรแต่การแก้ไขช้าบนโฮสต์ที่มีการใช้งานเต็มที่ ชี้ไปที่ความจุหรือภาระงาน

3. เลือกใช้โหมด Fast หรือ Strict สำหรับเวิร์กโฟลว์ ไม่ใช่เพื่อแก้ไขปัญหาที่เซิร์ฟเวอร์

ONLYOFFICE มีโหมดการแก้ไขร่วมแบบเร็ว (Fast co-editing) ซึ่งเป็นค่าเริ่มต้นและแสดงการแก้ไขของผู้ใช้รายอื่นแบบเรียลไทม์ และโหมดการแก้ไขร่วมแบบเข้มงวด (Strict co-editing) ซึ่งจะเก็บการเปลี่ยนแปลงไว้จนกว่าผู้ใช้จะบันทึกเอกสารเกี่ยวกับการแก้ไขร่วมอธิบายถึงความแตกต่างในการแสดงการเปลี่ยนแปลง โหมดเข้มงวดเหมาะสำหรับทีมที่ต้องการตรวจสอบและนำการเปลี่ยนแปลงไปใช้เป็นกลุ่ม ในขณะที่โหมดเร็วเป็นตัวเลือกที่เหมาะสมเมื่อต้องการเห็นการเปลี่ยนแปลงร่วมกันทันที

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

4. ปรับขนาดเฉพาะหลังจากที่การวัดระบุแรงดันความจุแล้วเท่านั้น

หากเกิดความล่าช้าในการแสดงผลเอกสารและผู้ใช้ ในขณะที่ CPU ทำงานหนัก หน่วยความจำมีจำกัด หรือคอนเทนเนอร์รีสตาร์ท ให้เพิ่มทรัพยากรโฮสต์ให้เพียงพอแก่ Document Server ก่อน และตรวจสอบว่าข้อจำกัดของ Docker ไม่ทำให้ทรัพยากรโฮสต์ลดลง จากนั้นจึงทำการทดสอบอีกครั้ง เอกสารอ้างอิง Docker รุ่น Community Edition ที่เผยแพร่ระบุ RAM 4 GB และข้อกำหนดพื้นที่จัดเก็บข้อมูลที่แตกต่างกันไปตามจำนวนผู้ใช้พร้อมกัน สำหรับผู้ใช้พร้อมกันมากกว่า 400 คน แนะนำให้ใช้การใช้งานแบบคลัสเตอร์และชี้ไปที่ Kubernetes ใช้ตัวเลขเหล่านั้นเป็นข้อมูลอ้างอิงในการวางแผน ไม่ใช่การรับประกันว่าเซิร์ฟเวอร์จะรองรับปริมาณงานที่เฉพาะเจาะจงได้

สำหรับการติดตั้งขนาดเล็ก การเพิ่ม CPU หรือหน่วยความจำที่มีอยู่มักจะทำได้ง่ายกว่าการแบ่งบริการออกเป็นหลายโฮสต์ สำหรับการใช้งานพร้อมกันในระดับสูงอย่างต่อเนื่อง บริการที่แยกจากกันหรือแบบคลัสเตอร์อาจให้พื้นที่ว่างมากกว่า แต่ก็เพิ่มการพึ่งพาเครือข่าย การกำหนดค่า การตรวจสอบ และจุดที่อาจเกิดความล้มเหลว ตัวอย่าง Compose อย่างเป็นทางการในปัจจุบันของ ONLYOFFICE มีการตรวจสอบสถานะของเอนด์พอยต์ Document Server ใช้สถานะของคอนเทนเนอร์และการตอบสนองของแอปพลิเคชันร่วมกัน แทนที่จะสันนิษฐานว่าคอนเทนเนอร์ที่ทำงานอยู่หมายถึงเส้นทางการแก้ไขที่ราบรื่น ควรตรึงเวอร์ชันของอิมเมจไว้ในระหว่างการวินิจฉัย เพื่อไม่ให้การอัปเดตการปรับใช้ทำให้การวัดก่อนและหลังเกิดความสับสน

ตรวจสอบการแก้ไขด้วยการทดสอบการแก้ไขแบบเดียวกัน

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

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