การเพิ่มประสิทธิภาพการใช้หน่วยความจำในแอปพลิเคชันการดูเอกสารขนาดใหญ่
คุณมี PDF, ไฟล์ Office หรือภาพวาด CAD จำนวนหลายพันไฟล์ที่ต้องแสดงใน พอร์ทัลที่ใช้ .NET? และคุณไม่ต้องการให้เซิร์ฟเวอร์ของคุณหมด RAM? เคล็ดลับคือการ ผสมผสานการสตรีมแบบ lazy, ปลั๊กอินที่กำหนดเป้าหมาย, และ pipeline การเรนเดอร์ที่ปรับแต่งของ Doconut. ในส่วนต่อไปเราจะพาไปสำรวจปัญหาที่เกี่ยวกับหน่วยความจำที่เกิดขึ้นในแอปพลิเคชันระดับองค์กรที่มีเอกสารจำนวนมาก, จากนั้นจะแสดงให้เห็นว่า Doconut—ตัวดูเอกสารสากลสำหรับแบ็กเอนด์ .NET—ทำอย่างไรให้ผ่านอุปสรรคที่ทำให้ตัวดูแบบดั้งเดิมไม่สามารถขยายได้. อ้อ, มี การทดลองใช้ฟรี รอคุณอยู่หากต้องการเห็นผลลัพธ์ในสภาพแวดล้อมของคุณเอง.
ทำความเข้าใจแรงกดดันหน่วยความจำในตัวดูเอกสาร .NET
พอร์ทัลเอกสารขนาดใหญ่มักจะโหลดไฟล์ทั้งหมดเข้าสู่หน่วยความจำก่อนที่หน้าหนึ่งจะปรากฏ. การวาด CAD ขนาด 200 MB หรือ PDF 500 หน้า สามารถทำให้ตัวเก็บขยะของ .NET ทำงานหนัก, ทำให้เกิดการหยุดทำงานของ GC แบบเต็ม, และบังคับให้คุณต้องจัดสรรเซิร์ฟเวอร์มากเกินความจำเป็น.
ทำไมโมเดลการเรนเดอร์ .NET เริ่มต้นจึงทำให้การขยายขนาดเป็นไปได้ยาก
| อาการ | สาเหตุทั่วไปในการนำไปใช้แบบไม่ระมัดระวัง |
|---|---|
| ข้อยกเว้นหน่วยความจำเต็ม | อาร์เรย์ไบต์ของไฟล์ทั้งหมดที่เก็บไว้ในแคชสถิต |
| การโหลดหน้าหนึ่งช้า | ถอดรหัสเอกสารทั้งหมดก่อนการเรนเดอร์ |
| การขาดแคลนเธรดพูล | การเรนเดอร์ที่ใช้ CPU เป็นเวลานานบล็อก pipeline แบบ async |
| การกระตุ้นความหน่วงเวลาที่ไม่คาดคิด | การเก็บของ GC ของอ็อบเจกต์ที่ถูก pin ขนาดใหญ่ |
เพิ่มปลั๊กอิน annotation หรือ OCR ที่เก็บบิตแมพของภาพไว้, แล้วแรงกดดันจะเพิ่มขึ้นหลายเท่า. จุดที่เหมาะสมคือการ ประมวลผลเฉพาะสิ่งที่ผู้ใช้ต้องการในขณะนั้น และทำให้บัฟเฟอร์กลางทุกตัวมีอายุสั้น.
คำตอบของ Doconut: แกนที่บางเบาและปรับแต่งการพึ่งพา
สถาปัตยกรรม .NET 6 ของ Doconut ถูกสร้างใหม่เพื่อ ลดการจัดสรร heap:
- การปรับแต่งการพึ่งพา – ไลบรารีจะโหลดโมดูลการเรนเดอร์ที่จำเป็นสำหรับประเภทไฟล์ปัจจุบัน (PDF, Office, CAD, image) เท่านั้น. ปลั๊กอินที่ไม่ได้ใช้จะไม่อยู่ในหน่วยความจำ, ทำให้รอยเท้าของกระบวนการเล็กลง.
- การออกแบบแบบสตรีม‑แรก – ไฟล์จะถูกเปิดเป็นสตรีม, ไม่ใช่อาร์เรย์ไบต์ทั้งหมด, ทำให้ runtime สามารถดึงข้อมูลจากดิสก์ตามความต้องการ.
- การสนับสนุนงานเบื้องหลัง – งานแปลงที่หนักสามารถส่งต่อไปยังกระบวนการ worker หรือ Azure Functions, ทำให้ชั้นเว็บว่างสำหรับการดูแบบโต้ตอบ.
เมื่อคุณจัดตัวดูให้สอดคล้องกับรูปแบบ async ของ .NET, Doconut จะทำให้คุณให้บริการเซสชันพร้อมกันหลายพันบนคลัสเตอร์ VM ขนาดพอเหมาะ.
วิธีเปิดใช้งานการโหลดแบบ lazy
- ลงทะเบียน middleware ของ Doconut ใน pipeline ของ ASP.NET Core ของคุณ. Middleware จะดักจับคำขอตัวดูและแทรกบริการที่จำเป็น.
- เปิดเอกสารเป็นสตรีม แทนการโหลดไฟล์ทั้งหมด. เมธอด
OpenDocumentของ Doconut รับพาธไฟล์หรือสตรีมและคืนโทเค็นที่แทนเอกสารที่เปิด. - ขอหน้าตามความต้องการ จากฝั่งไคลเอนต์. เมื่อส่วนหน้าเรียกหน้าที่ระบุ, Doconut จะอ่านอ็อบเจกต์ที่จำเป็น, เรนเดอร์ภาพเรสเตอร์, และส่งคืนภาพย่อที่มีน้ำหนักเบา.
เนื่องจากตัวดูทำงานกับ สตรีม, คุณสามารถเก็บไฟล์ใน Azure Blob Storage, Amazon S3, หรือ NAS ภายในองค์กรโดยไม่ต้องคัดลอกไปยังดิสก์ท้องถิ่นของเว็บเซิร์ฟเวอร์. ระบบปฏิบัติการจะทำการเพจ, และ .NET runtime จะถือบัฟเฟอร์ขนาดเล็กที่จำเป็นสำหรับหน้าที่ใช้งาน.
ประโยชน์สำหรับการใช้งานขนาดใหญ่
| ประโยชน์ | วิธีที่ Doconut ทำได้ |
|---|---|
| การใช้ RAM ที่คาดการณ์ได้ | แคชหน้าขนาดคงที่ + การเข้าถึงแบบสตรีมเท่านั้น |
| การเรนเดอร์หน้าหนึ่งที่เร็ว | อ่านเฉพาะส่วนหัวของเอกสารและอ็อบเจกต์ของหน้าหนึ่งแรก |
| ขยายได้ข้ามเบราว์เซอร์ | ตรรกะแบบสตรีมเดียวกันทำงานกับ front‑end HTML5/React, Angular หรือ Vue |
| ลดแรงกดดันของ GC | ไม่มีอาร์เรย์ไบต์ที่ pin ขนาดใหญ่; บัฟเฟอร์ทั้งหมดมีอายุสั้น |
ผสานการโหลดแบบ lazy กับงานแปลงเบื้องหลัง, แล้วชั้นเว็บจะไม่หยุดชะงักจากการแปลงที่ใช้ CPU หนัก.
ปลั๊กอิน Annotation และ OCR ของ .NET โดยไม่มีภาระเกินจำเป็น
องค์กรต่าง ๆ ชื่นชอบ annotation และ OCR ที่ค้นหาได้, แต่วิธีที่ไม่ระมัดระวังจะเก็บบิตแมพความละเอียดเต็มของทุกหน้าในหน่วยความจำเพื่อวาดไฮไลท์หรือทำการจดจำข้อความ. โมเดลปลั๊กอินของ Doconut แยกคุณลักษณะเหล่านี้ออกเป็นบริการอิสระที่ทำงานตามความต้องการ.
Annotation – การจัดการแบบเบา, ต่อหน้า
เมื่อโหลดหน้า, คุณสามารถดึงตัวจัดการ annotation ที่เก็บเฉพาะข้อมูลเวกเตอร์ (พิกัด, สไตล์, โน้ต). การเพิ่มสแตมป์หรือไฮไลท์จะอัปเดตเวกเตอร์สโตร์; บิตแมพพื้นฐานจะไม่ถูกทำซ้ำ. Doconut จะเรนเดอร์หน้าซ้ำพร้อมโอเวอร์เลย์เมื่อไคลเอนต์ร้องขอ, ดังนั้นแม้ PDF 500 หน้า ที่มี annotation จำนวนหลายพันก็ใช้หน่วยความจำเพียงส่วนเล็กของโซลูชันที่อิงบิตแมพ.
OCR – การสกัดข้อความแบบเรียลไทม์
Search Plugin ทำ OCR เฉพาะบนหน้าที่ผู้ใช้เลื่อนถึง. คุณกำหนดความละเอียดภาพที่ต้องการ (เช่น 200 dpi) ในตัวเลือกเอกสาร, แล้ว Doconut จะสกัดข้อความสำหรับหน้าปัจจุบัน, เก็บผลลัพธ์ใน ดัชนีบีบอัด ที่เชื่อมกับโทเค็นเอกสาร. กระบวนการ OCR แยกจากการเรนเดอร์, ทำให้คุณสามารถขยายแนวนอนได้ (เช่น ผ่าน Azure Functions) โดยไม่เพิ่มขนาดหน่วยความจำของเว็บเซิร์ฟเวอร์ที่ให้บริการตัวดู.
ทำไมเรื่องนี้สำคัญสำหรับองค์กรขนาดใหญ่
- ต้นทุนที่คาดการณ์ได้ – annotation และ OCR ทำงานต่อหน้า, ไม่ใช่ต่อเอกสาร, ทำให้การใช้หน่วยความจำเป็นเชิงเส้นกับเนื้อหาที่มองเห็น.
- พร้อมการปฏิบัติตาม – annotation ถูกเก็บเป็น XML, ทำให้การตรวจสอบหรือการลบข้อมูลเป็นเรื่องง่าย.
- ความปลอดภัยแบบหลายผู้เช่า – โทเค็นของแต่ละผู้เช่าจะแยกดัชนี OCR ของตน, ป้องกันการรั่วไหลของข้อมูลระหว่างผู้เช่า.
การแปลงฝั่งเซิร์ฟเวอร์และการพิมพ์ที่ควบคุม: ทำให้ภาระงานมีประสิทธิภาพ
พอร์ทัลหลายแห่งต้อง แปลง ไฟล์ Office, ภาพวาด CAD, หรือข้อความอีเมลเป็น PDF หรือรูปภาพเพื่อการเรนเดอร์ที่สอดคล้องกัน. กับดักทั่วไปคือการทำการแปลงในกระบวนการเดียว, ซึ่งทำให้ RAM และ CPU พุ่งสูงขณะผู้ใช้รอ. Converter Plugin ของ Doconut ย้ายงานหนักไปยัง บริการฝั่งเซิร์ฟเวอร์ ที่คุณสามารถขยายแนวนอนได้.
การแปลงโดยไม่โหลดไฟล์ต้นฉบับทั้งหมด
API การแปลงรับพาธต้นทางและปลายทาง (หรือสตรีม) และทำงานแบบสตรีม, ดังนั้นไฟล์ต้นทางจะไม่ถูกทำให้เต็มในหน่วยความจำ. เมื่อ PDF (หรือรูปแบบเป้าหมายอื่น) พร้อม, ตัวดูจะเปิดโดยใช้เทคนิคการโหลดแบบ lazy เดียวกันที่อธิบายไว้ก่อนหน้า.
การพิมพ์ที่ควบคุม – หลีกเลี่ยงการเรนเดอร์ภาพเต็มเอกสาร
เมื่อพิมพ์ PDF ขนาดใหญ่, Doconut จะสตรีม งานพิมพ์หน้า‑ต่อหน้า ไปยังไดรเวอร์เครื่องพิมพ์. วิธีนี้ทำให้คุณสามารถบังคับโควต้าหรือลายน้ำได้โดยไม่ต้องโหลดเอกสารทั้งหมดเข้าสู่ RAM.
การขยายระดับองค์กร
| สถานการณ์ | เทคนิคการประหยัดหน่วยความจำของ Doconut |
|---|---|
| การแปลงแบบแบตช์ของไฟล์ Office 10 000 ไฟล์ | ใช้ worker เบื้องหลังที่ทำการแปลงแบบสตรีม; แต่ละ worker จัดการไฟล์หนึ่งไฟล์ในแต่ละครั้ง, ทำให้ RAM ต่ำ. |
| การพิมพ์ตามความต้องการของภาพวาด CAD 5 หลัก | พิมพ์ผ่านสตรีมหน้า; ไม่ต้องเรนเดอร์ภาพวาดเต็ม. |
| พอร์ทัล SaaS แบบหลายผู้เช่า | แยกคิวการแปลงตามผู้เช่า; การแยกหน่วยความจำทำงานอัตโนมัติเพราะแต่ละงานทำงานบนสตรีมของตนเอง. |
แนวทางปฏิบัติที่ดีที่สุดสำหรับการขยาย Doconut ในสภาพแวดล้อมองค์กร
แม้จะมีเอนจินที่ใช้หน่วยความจำอย่างมีประสิทธิภาพ, การใช้งานจริงยังต้องการแนวป้องกันบางอย่าง. ด้านล่างเป็นแนวทางที่พิสูจน์แล้วที่ช่วยเพิ่มจุดแข็งในตัวของ Doconut.
1. จำกัดขนาดแคชหน้าต่อเซสชัน
ตั้งค่าตัวดูให้เก็บเฉพาะหน้าล่าสุดในหน่วยความจำ. การลดขนาดแคชจะทำให้การใช้ RAM ต่อเซสชันลดลงโดยตรง.
2. รัน OCR และการแปลงในไมโครเซอร์วิสที่แยกจากกัน
ปรับใช้ Search Plugin และ Converter Plugin เป็นคอนเทนเนอร์แยกที่อยู่หลังคิวข้อความ (RabbitMQ, Azure Service Bus, ฯลฯ). วิธีนี้แยกการพุ่งของหน่วยความจำและทำให้คุณสามารถสเกลอัตโนมัติแต่ละคอมโพเนนต์ได้อย่างอิสระ.
3. เปิดใช้งาน Trim และ ReadyToRun ของ .NET 6
เมื่อทำการเผยแพร่ API ที่ใช้ Doconut, เปิดใช้งานการตัด (trim) เพื่อลบ IL ที่ไม่ได้ใช้และลดขนาดไบนารี:
dotnet publish -c Release -r win-x64 --self-contained true /p:PublishTrimmed=true
ไบนารีที่เล็กลงหมายถึงชุดทำงานที่เล็กลง, ซึ่งแปลว่า RAM ต่อคอนเทนเนอร์น้อยลง.
สรุป
การเพิ่มประสิทธิภาพการใช้หน่วยความจำเป็นสิ่งสำคัญสำหรับโซลูชันการดูเอกสารขนาดใหญ่. ด้วยการใช้ สถาปัตยกรรมแบบสตรีม‑first, แกนที่ปรับแต่งการพึ่งพา, และ ปลั๊กอิน annotation/OCR ตามความต้องการ ของ Doconut, คุณสามารถทำให้การใช้ RAM คาดการณ์ได้ในขณะที่มอบประสบการณ์การดูที่เร็วและตอบสนอง. ปรับใช้รูปแบบแนวทางปฏิบัติที่แนะนำ—แคชโทเค็นแบบกระจาย, จำกัดการแคชหน้า, การแยกไมโครเซอร์วิส, และการสร้างแบบ trimmed—และคุณจะเปิดศักยภาพการขยายเต็มของ Doconut.
พร้อมที่จะเห็นความแตกต่างด้วยตัวคุณเองหรือยัง? เริ่มทดลองใช้ Doconut ฟรีวันนี้ และสัมผัสการดูเอกสารที่ใช้หน่วยความจำน้อย, มีประสิทธิภาพสูงในแอปพลิเคชัน .NET ของคุณ.