ป้องกันการหมดเวลาในการส่งออก: งานอะซิงค์ ความคืบหน้า การสตรีม

ทำไมการส่งออกถึงหมดเวลา อธิบายแบบตรงไปตรงมา

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

บนหน้าจอ มักจะเป็นหนึ่งในรูปแบบเหล่านี้:

• ไอคอนหมุนที่ไม่หยุด
• การดาวน์โหลดเริ่มแล้วหยุดพร้อม "ข้อผิดพลาดเครือข่าย"
• หน้าแสดงข้อผิดพลาดหลังรอนาน
• ไฟล์ที่ดาวน์โหลดมาแต่เปล่าหรือเสียหาย

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

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

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

ถ้าต้องการป้องกันการหมดเวลา ให้มองการส่งออกเป็นงานพื้นหลัง ไม่ใช่การโหลดหน้าโดยปกติ แม้ในเครื่องมือ no-code อย่าง AppMaster แบบแผนสำคัญกว่าตัวเครื่องมือ: งานที่ใช้เวลานานต้องการโฟลว์ต่างจาก "คลิกปุ่ม รอการตอบกลับ"

เลือกรูปแบบการส่งออกที่เหมาะสมกับแอปของคุณ

ความล้มเหลวส่วนใหญ่มาจากการใช้รูปแบบเดียวกับทุกสถานการณ์ ทั้งๆ ที่ขนาดข้อมูลและเวลาประมวลผลต่างกันมาก

การส่งออกแบบ synchronous ง่ายๆ (ผู้ใช้คลิก เซิร์ฟเวอร์สร้าง ดาวน์โหลดเริ่ม) เหมาะเมื่อการส่งออกเล็กและคาดเดาได้ คิดว่าไม่กี่ร้อยแถว คอลัมน์พื้นฐาน ไม่มีฟอร์แมตหนัก และไม่มีผู้ใช้จำนวนมากพร้อมกัน หากเสร็จในไม่กี่วินาทีบ่อยๆ แบบที่เรียบง่ายมักจะดีที่สุด

สำหรับงานที่ยาวหรือไม่แน่นอน ให้ใช้งานส่งออกอะซิงค์ (async export jobs) เหมาะกับชุดข้อมูลขนาดใหญ่ การคำนวณซับซ้อน งานเลย์เอาต์ PDF และเซิร์ฟเวอร์ที่แชร์ซึ่งงานช้าอาจบล็อกคำขออื่นๆ

งานอะซิงค์เหมาะเมื่อ:

• การส่งออกมักใช้เวลาเกิน 10–15 วินาที
• ผู้ใช้ขอช่วงวันที่กว้างหรือ "ตลอดเวลา"
• สร้าง PDF ที่มีชาร์ต รูปภาพ หรือหลายหน้า
• ทีมหลายทีมส่งออกในชั่วโมงพีค
• ต้องการการรีไทรที่ปลอดภัยเมื่อเกิดข้อผิดพลาด

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

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

ทีละขั้นตอน: สร้างงานส่งออกอะซิงค์

การเปลี่ยนแปลงที่ใหญ่ที่สุดก็เรียบง่าย: หยุดสร้างไฟล์ภายในคำขอเดียวกับที่ผู้ใช้คลิก

งานส่งออกอะซิงค์แบ่งงานเป็นสองส่วน: คำขอเร็วที่สร้างงาน และงานเบื้องหลังที่สร้างไฟล์ขณะที่แอปยังตอบสนองได้

โฟลว์ใช้งานจริง 5 ขั้นตอน

1. เก็บคำขอส่งออก (ใครขอ, ตัวกรอง, คอลัมน์ที่เลือก, รูปแบบผลลัพธ์)
2. สร้างเรคอร์ดงานพร้อมสถานะ (queued, running, done, failed), เวลาประทับ และฟิลด์ข้อผิดพลาด
3. รันงานหนักในเบื้องหลังด้วยคิว worker ตามเวลา หรือโปรเซสเวิร์กเกอร์ที่แยกต่างหาก
4. เขียนผลลัพธ์ไปยังสตอเรจ (object storage หรือไฟล์สโตร์) แล้วบันทึกลิงก์ดาวน์โหลดในเรคอร์ดงาน
5. แจ้งผู้ใช้เมื่อพร้อมด้วยการแจ้งในแอป อีเมล หรือช่องทางข้อความที่ทีมใช้แล้ว

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

ตัวอย่าง: ผู้จัดการซัพพอร์ตส่งออกรายการตั๋วจากไตรมาสที่ผ่านมา แทนที่จะรอแท็บหมุน พวกเขาจะเห็นรายการงานจาก queued ไปเป็น done แล้วปุ่มดาวน์โหลดปรากฏ ใน AppMaster คุณสามารถโมเดลตารางงานใน Data Designer สร้างตรรกะเบื้องหลังใน Business Process Editor และใช้ฟิลด์สถานะเพื่อขับเคลื่อนสถานะ UI

ตัวชี้วัดความคืบหน้าที่ผู้ใช้เชื่อถือได้จริงๆ

ตัวบ่งชี้ความคืบหน้าที่ดีลดความกังวลและหยุดคนจากการกด Export ซ้ำ มันยังช่วยป้องกันการหมดเวลาโดยทางอ้อม เพราะผู้ใช้ยินดีรอเมื่อแอปแสดงความคืบหน้าจริง

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

• ขั้นตอนปัจจุบัน (Preparing data, Fetching rows, Building file, Uploading, Ready)
• แถวที่ประมวลผลจากทั้งหมด (หรือหน้าที่ประมวลผล)
• เวลาเริ่มและเวลาที่อัปเดตล่าสุด
• เวลาที่เหลือโดยประมาณ (แสดงเฉพาะเมื่อค่อนข้างนิ่ง)

หลีกเลี่ยงความแม่นยำปลอม หากยังไม่รู้จำนวนงานทั้งหมด อย่าแสดง 73% ใช้มาตรไมล์ก่อน แล้วสลับเป็นเปอร์เซ็นต์เมื่อรู้ตัวส่วนหนึ่ง แพทเทิร์นง่ายคือ 0–10% สำหรับการตั้งค่า, 10–90% ตามแถวที่ประมวลผล, และ 90–100% สำหรับการสรุปไฟล์ สำหรับ PDF ที่มีขนาดเพจไม่คงที่ ให้ติดตามความจริงย่อย เช่น "records rendered" หรือ "sections completed"

อัปเดตบ่อยพอให้รู้สึกมีชีวิต แต่ไม่บ่อยจนกระทบฐานข้อมูลหรือคิว แนวทางปกติคือเขียนความคืบหน้าทุก 1–3 วินาที หรือทุก N แถว (เช่น ทุก 500 หรือ 1,000 แถว) แล้วแต่แบบไหนน้อยกว่า นอกจากนี้บันทึก heartbeat timestamp เบาๆ เพื่อให้ UI พูดว่า "ยังทำงานอยู่" แม้เปอร์เซ็นต์ไม่ขยับ

ให้ผู้ใช้ควบคุมเมื่อใช้เวลานาน ให้พวกเขายกเลิกการส่งออกที่กำลังรัน เริ่มงานใหม่โดยไม่ทำให้ของเดิมหายไป และดูประวัติการส่งออกพร้อมสถานะ (Queued, Running, Failed, Ready) และข้อความข้อผิดพลาดสั้นๆ

ใน AppMaster เรคอร์ดทั่วไปจะเป็น ExportJob (status, processed_count, total_count, step, updated_at) UI โพลเรคอร์ดนั้นและแสดงความคืบหน้าที่ตรงไปตรงมาขณะที่งานอะซิงค์สร้างไฟล์ในเบื้องหลัง

การแบ่งหน้าและการกรองเพื่อควบคุมขอบเขตงาน

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

เริ่มจากเป้าหมายของผู้ใช้ หากใครต้องการ "ใบแจ้งหนี้เดือนที่แล้วที่ล้มเหลว" อย่าเริ่มต้นด้วยค่าเริ่มต้นเป็น "ทุกใบแจ้งหนี้เท่าที่มี" ทำให้การกรองเป็นเรื่องปกติ ไม่ใช่งานเบื้องหลังให้ผู้ใช้รำคาญ ช่วงวันที่ที่เหมาะสม (เช่น 7 หรือ 30 วันที่ผ่านมา) และการกรองสถานะที่สำคัญมักลดชุดข้อมูลได้มาก

ฟอร์มการส่งออกที่ดีมักมีช่วงวันที่ (ดีฟอลต์ที่สมเหตุสมผล), สถานะหลักหนึ่งหรือสองอย่าง, การค้นหา/การเลือกลูกค้าหรือทีมแบบเลือกได้ และการแสดงตัวอย่างจำนวนแถวเมื่อเป็นไปได้ (แม้จะเป็นการประมาณ)

ฝั่งเซิร์ฟเวอร์ ให้อ่านข้อมูลเป็นชิ้นโดยใช้การแบ่งหน้า วิธีนี้ทำให้หน่วยความจำคงที่และให้จุดตรวจความคืบหน้าตามธรรมชาติ เสมอใช้การจัดเรียงที่คงที่เมื่อแบ่งหน้า (เช่น order by created_at แล้วตามด้วย id) หากไม่ทำ แถวใหม่อาจเลื่อนเข้ามาในหน้าก่อนและคุณจะพลาดหรือทำซ้ำข้อมูล

ข้อมูลเปลี่ยนระหว่างการส่งออกยาวๆ ดังนั้นตัดสินใจว่า "คงที่" หมายถึงอะไร วิธีง่ายคือบันทึกเวลาสแน็ปชอตเมื่องานเริ่ม แล้วส่งออกเฉพาะแถวจนถึงเวลานั้น หากต้องการความสอดคล้องเข้มงวด ใช้ consistent read หรือ transaction ตามที่ฐานข้อมูลรองรับ

ในเครื่องมือ no-code อย่าง AppMaster สิ่งนี้แมปได้ชัดเจนใน business process: ตรวจสอบตัวกรอง ตั้งสแน็ปชอตเวลา แล้ววนผ่านหน้าจนกว่าจะไม่เหลือข้อมูลให้ดึง

การสตรีมดาวน์โหลดโดยไม่ทำให้เซิร์ฟเวอร์ล้ม

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

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

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

เฮดเดอร์ ชื่อไฟล์ และชนิดเนื้อหา

ใช้เฮดเดอร์ชัดเจนเพื่อให้เบราว์เซอร์และแอปมือถือจัดการดาวน์โหลดถูกต้อง ตั้ง content type ให้เหมาะสม (เช่น text/csv หรือ application/pdf) และชื่อไฟล์ที่ปลอดภัย ชื่อไฟล์ควรหลีกเลี่ยงอักขระพิเศษ สั้น และใส่ timestamp ถ้าผู้ใช้ส่งออกรายงานเดียวกันบ่อยๆ

การต่อหรือดาวน์โหลดแบบบางส่วน

ตัดสินใจก่อนว่ารองรับการต่อหรือไม่ การสตรีมพื้นฐานมักไม่รองรับ Range resume โดยเฉพาะสำหรับ PDF ที่สร้างขึ้น ถ้าต้องการรองรับ ต้องจัดการ Range requests และสร้างเอาต์พุตที่สอดคล้องสำหรับงานเดียวกัน

ก่อนส่ง ให้แน่ใจว่าคุณ:

• ส่งเฮดเดอร์ก่อนเขียนบอดี้ แล้วเขียนเป็นชิ้นและ flush
• รักษาขนาดชิ้นให้คงที่เพื่อให้หน่วยความจำคงตัวภายใต้โหลด
• ใช้การจัดเรียงที่กำหนดได้เพื่อให้ผู้ใช้ไว้ใจผลลัพธ์
• ระบุว่า resume รองรับหรือไม่ และเกิดอะไรขึ้นถ้าการเชื่อมต่อหลุด
• ใส่ขีดจำกัดฝั่งเซิร์ฟเวอร์ (max rows, max time) และส่งข้อผิดพลาดที่เป็นมิตรเมื่อเกิน

ถ้าสร้างการส่งออกใน AppMaster ให้เก็บตรรกะการสร้างใน flow ฝั่งเซิร์ฟเวอร์และสตรีมจากเซิร์ฟเวอร์ ไม่ใช่จากเบราว์เซอร์

การส่งออก CSV ขนาดใหญ่: กลยุทธ์ปฏิบัติได้จริง

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

เขียน CSV แถวต่อแถว แม้จะสร้างในงานอะซิงค์ก็หลีกเลี่ยงการ "เก็บทุกแถวไว้แล้วค่อยแปลงเป็นสตริง" เปิด writer แล้วต่อแถวแต่ละแถวเมื่อพร้อม หากสแต็ครองรับ ให้ใช้ database cursor หรือแบ่งหน้าเพื่อไม่โหลดเรคอร์ดล้านเรคอร์ดพร้อมกัน

ความถูกต้องของ CSV สำคัญเท่ากับความเร็ว ไฟล์อาจดูปกติจนกว่าจะเปิดใน Excel แล้วคอลัมน์เลื่อน

กฎ CSV ที่ป้องกันไฟล์พัง

• หนีเครื่องหมายจุลภาค เครื่องหมายคำพูด และ newline เสมอ (ห่อฟิลด์ทั้งหมดด้วยเครื่องหมายคำพูด, และทำเครื่องหมายคำพูดภายในเป็นสองครั้ง)
• เอาต์พุตเป็น UTF-8 และทดสอบชื่อนอกภาษาอังกฤษแบบ end-to-end
• ใช้แถวหัวข้อคงที่และลำดับคอลัมน์คงที่ข้ามการรัน
• ปรับวันที่และทศนิยมให้เป็นรูปแบบเดียวกัน
• หลีกเลี่ยงสูตรหากข้อมูลอาจเริ่มด้วย =, +, -, หรือ @

ประสิทธิภาพมักล่มที่การเข้าถึงข้อมูล ไม่ใช่การเขียน ระวัง N+1 lookups (เช่น โหลดลูกค้าแต่ละแถวในลูป) ดึงข้อมูลที่เกี่ยวข้องในคิวรีเดียวหรือ preload สิ่งที่ต้องการแล้วเขียนแถว

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

ถ้าใช้ AppMaster ให้โมเดลชุดข้อมูลใน Data Designer และรันการส่งออกเป็น business process เบื้องหลัง เขียนแถวขณะวนหน้าผ่านเรคอร์ด

การส่งออก PDF ขนาดใหญ่: ทำให้คาดเดาได้

การสร้าง PDF มักช้ากว่า CSV เพราะหนักที่ CPU คุณไม่ได้แค่ย้ายข้อมูล แต่ต้องเลย์เอาต์หน้า วางฟอนต์ วาดตาราง และย่อ/ยืดรูปภาพ พิจารณา PDF เป็นงานเบื้องหลังพร้อมขอบเขตชัดเจน ไม่ใช่การตอบกลับเร็ว

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

การตัดสินใจเทมเพลตที่มักช่วยได้:

• ใช้ฟอนต์หนึ่งหรือสองแบบและหลีกเลี่ยง fallback chains หนักๆ
• เก็บ header/ footer ให้เรียบง่าย (หลีกเลี่ยงชาร์ตไดนามิกบนทุกหน้า)
• ใช้ไอคอนเวกเตอร์แทนภาพแรสเตอร์ขนาดใหญ่
• จำกัดเลย์เอาต์แบบ "auto fit" ที่วัดข้อความซ้ำหลายครั้ง
• หลีกเลี่ยงความโปร่งใสและเงาที่ซับซ้อน

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

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

ใน AppMaster สิ่งนี้เข้าได้ดี: รันการสร้าง PDF เป็นงานพื้นหลัง รายงานความคืบหน้า และส่งมอบไฟล์เมื่องานเสร็จ

ข้อผิดพลาดทั่วไปที่ทำให้หมดเวลา

การล้มเหลวของการส่งออกมักไม่ลึกลับ ตัวเลือกไม่กี่อย่างใช้งานได้กับ 200 แถว แต่พังที่ 200,000 แถว

ข้อผิดพลาดที่พบบ่อยที่สุด:

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

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

ถ้าสร้างด้วยเครื่องมือ no-code อย่าง AppMaster กฎเดิมยังใช้: เอาการส่งออกออกจากเส้นทางคำขอ ติดตามความคืบชั่วจากแถวที่ประมวลผล เขียนขณะไป และใส่ขอบเขตจำนวนส่งออกที่ผู้ใช้รันพร้อมกัน

การตรวจสอบด่วนก่อนปล่อย

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

เช็คลิสต์ก่อนขึ้น:

• การส่งออกใหญ่รันเป็น background jobs (แบบเล็กสามารถ synchronous ได้ถ้าเสร็จเร็วแน่นอน)
• ผู้ใช้เห็นสถานะชัดเจนเช่น queued, running, done, failed พร้อมเวลาประทับ
• อ่านข้อมูลเป็นชิ้นด้วยการจัดเรียงที่คงที่ (เช่น created time บวก tie-breaker เป็น ID)
• ไฟล์ที่เสร็จสามารถดาวน์โหลดได้ทีหลังโดยไม่ต้องรันการส่งออกใหม่ แม้ผู้ใช้ปิดแท็บ
• มีแผนจำกัดและล้างไฟล์เก่า (ลบตามอายุ, max jobs ต่อผู้ใช้, ขีดจำกัดสตอเรจ)

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

ถ้าสร้างบน AppMaster การตรวจสอบเหล่านี้แผนผังชัดเจน: กระบวนการเบื้องหลังใน Business Process Editor, เรคอร์ดงานในฐานข้อมูล, และฟิลด์สถานะที่ UI อ่านและรีเฟรช

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

ตัวอย่าง: ส่งออกรายปีโดยไม่ทำให้แอปค้าง

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

เริ่มจากจำกัดงาน หน้าการส่งออกขอช่วงวันที่ (ดีฟอลต์: 30 วันที่ผ่านมา), ตัวกรองเลือกได้ (สถานะ, ภูมิภาค, พนักงานขาย), และรายการคอลัมน์ที่ชัดเจน การเปลี่ยนแปลงเพียงอย่างเดียวมักจะแปลงปัญหา 2 ปี 2 ล้านแถวให้จัดการได้

เมื่อผู้ใช้คลิก Export แอปสร้างเรคอร์ด Export Job (type, filters, requested_by, status, progress, error_text) และนำเข้าคิว ใน AppMaster นี่คือโมเดล Data Designer บวก Business Process ที่รันในเบื้องหลัง

ขณะงานรัน UI แสดงสถานะที่เชื่อถือได้: queued, processing (เช่น 3 จาก 20 ชิ้น), generating file, ready (ปุ่มดาวน์โหลด) หรือ failed (ข้อความชัดเจนและรีไทร)

การแบ่งหน้าเป็นรายละเอียดสำคัญ งาน CSV อ่านคำสั่งซื้อเป็นหน้า (เช่น 50,000 ต่อหน้า) เขียนแต่ละหน้าไปยังเอาต์พุต และอัปเดตความคืบหน้าหลังแต่ละชิ้น งาน PDF ทำแบบเดียวกันแบบแบตช์ต่อเดือน ดังนั้นเดือนหนึ่งที่ช้าจะไม่บล็อกทั้งหมด

ถ้ามีข้อผิดพลาด (ฟิลเตอร์ผิด สิทธิ์ไม่พอ สตอเรจล้ม) งานจะถูกทำเครื่องหมายเป็น Failed พร้อมข้อความสั้นที่ผู้ใช้ทำอะไรได้ เช่น "ไม่สามารถสร้างใบแจ้งหนี้เดือนมีนาคม กรุณาลองใหม่ หรือแจ้งทีมสนับสนุนพร้อม Job ID 8F21" การรีไทรใช้ฟิลเตอร์เดิมเพื่อให้ผู้ใช้ไม่ต้องเริ่มต้นใหม่

ขั้นตอนถัดไป: ทำให้การส่งออกเป็นฟีเจอร์มาตรฐาน ไม่ใช่การดับเพลิง

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

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

ทำให้ค้นหาการส่งออกที่สร้างแล้วง่าย หน้าประวัติการส่งออก (แยกตามผู้ใช้ workspace หรือบัญชี) ลดการส่งออกซ้ำ ช่วยทีมซัพพอร์ตตอบคำถาม "ไฟล์ของฉันอยู่ไหน?" และเป็นที่แสดงสถานะ ข้อผิดพลาด และการหมดอายุ

ถ้าสร้างแบบแผนนี้ใน AppMaster ช่วยได้ตรงที่แพลตฟอร์มสร้างซอร์สโค้ดจริงและรองรับตรรกะแบ็กเอนด์ การออกแบบฐานข้อมูล และ UI เว็บ/โมบายในที่เดียว สำหรับทีมที่ต้องส่งงานอะซิงค์รวดเร็ว appmaster.io มักใช้เพื่อสร้างตารางงาน กระบวนการเบื้องหลัง และ UI ความคืบหน้าโดยไม่ต้องเดินสายทุกอย่างเอง

จากนั้นวัดสิ่งที่ทำให้ปวด ให้ติดตามคิวรีฐานข้อมูลช้า เวลาที่ใช้ในการสร้าง CSV และเวลาการเรนเดอร์ PDF คุณไม่ต้องมี observability สมบูรณ์เพื่อเริ่ม: การล็อกระยะเวลาและจำนวนแถวต่อการส่งออกจะแสดงได้เร็วว่ารายงานหรือชุดตัวกรองใดเป็นปัญหา

ปฏิบัติต่อการส่งออกเหมือนฟีเจอร์ผลิตภัณฑ์อื่นๆ: สม่ำเสมอ วัดได้ และดูแลได้ง่าย