- ในสภาพแวดล้อม JavaScript และ Node.js ไลบรารีตรวจสอบความถูกต้องอย่าง Joi มีประสิทธิภาพช้ากว่าไลบรารีอื่น
- หากเปลี่ยนจาก Joi ไปใช้ไลบรารีอื่น ก็คาดหวังการปรับปรุงประสิทธิภาพได้ในสภาพแวดล้อมแบ็กเอนด์
- ทดสอบว่าความต่างด้านประสิทธิภาพที่มีนัยสำคัญสามารถเกิดขึ้นได้หรือไม่ในแอปพลิเคชันแบ็กเอนด์
- ทำการทดสอบด้วย k6 และทดสอบ lodash กับ class-transformer ไปพร้อมกันด้วย
- ผลการทดสอบประสิทธิภาพ:
- native vs lodash: ไม่มีความต่างด้านประสิทธิภาพ
- object literal vs class-transformer: ไม่มีความต่างด้านประสิทธิภาพ
- non-validation vs Joi: แม้ Joi จะช้ากว่า แต่ก็ไม่พบความต่างด้านประสิทธิภาพ
- ประสิทธิภาพเป็นเรื่องสำคัญ แต่ในการเปลี่ยนแปลงโปรเจกต์ที่กำลังดำเนินอยู่ อาจไม่รู้สึกถึงความต่างด้านประสิทธิภาพเมื่อเทียบกับเวลาที่ลงทุนไป
8 ความคิดเห็น
ผมคิดว่าสิ่งที่ผู้เขียนต้องการจะสื่อคงไม่ใช่ว่ามุ่งแก้สถานการณ์คอขวด แต่เป็นการบอกว่าในสภาพแวดล้อมที่ใกล้เคียงกับการใช้งานจริง ความแตกต่างด้านประสิทธิภาพของไลบรารีสำหรับตรวจสอบความถูกต้องนั้นไม่ได้มีนัยสำคัญมากนัก
ถ้าสมมติว่าไม่ใช่บริการที่มีแต่งานแบบ io bound ตามที่อธิบายไว้ในบทความ แต่เป็นบริการที่มีงานแบบ cpu bound ล่ะ จะเป็นอย่างไร?
บริการในสภาพแวดล้อมจริงซับซ้อนกว่าที่คิด เซิร์ฟเวอร์ไม่ได้มีไว้แค่เป็น data serving API ที่จำเป็นต่อการวาด UI เท่านั้น
งานอย่าง Validation และ JSON serialization เป็นการประมวลผลที่เกิดขึ้นบน main thread จึงไม่ใช่เรื่องที่มองข้ามได้ง่าย ๆ ในฝั่ง TS backend สิ่งที่ใช้กันแพร่หลายที่สุดคือ class-validator/class-transformer และตัวนี้มีปริมาณงานตรวจสอบที่รองรับได้ราว 4MB ต่อวินาที ซึ่งหมายความว่าบน main thread จะประมวลผลได้ไม่เกิน 4MB ต่อวินาทีนั่นเอง
ส่วนการรับส่งข้อมูลกับ DB นั้นทำงานบน background thread ไม่ใช่ main thread จึงโดยทั่วไปไม่ได้ส่งผลต่อจำนวนการเชื่อมต่อพร้อมกันของ backend server มากนัก (ในกรณีของเซิร์ฟเวอร์ TS) แต่ขึ้นอยู่กับลักษณะของบริการด้วย หากปริมาณ DTO ที่ส่งในครั้งเดียวมีขนาดใหญ่ ความช้าของ validation อาจน่ากลัวยิ่งกว่าเสียอีก (เคยมีกรณีจริงที่สร้างบริการซึ่งมีข้อมูลต่อคำขอขนาดใหญ่ แล้ว NestJS รองรับการเชื่อมต่อพร้อมกันได้แค่เลขหลักเดียว)
เห็นด้วยครับ ถ้าจะตั้งสมมติฐานตามที่ผู้เขียนยืนยันว่าเป็น "สถานการณ์จริง" ตัวอย่างสถานการณ์จริงที่ยกมานั้นแคบเกินไปมาก
เป็นเบนช์มาร์กที่ยากจะเข้าใจว่าทำไมถึงมีการใส่ DB I/O เข้ามา ตามที่คอมเมนต์ด้านบนบอกไว้ และ
validationกับserializationที่ช้านั้น เมื่อเทียบกับ request DTO แล้ว ผลเสียต่อประสิทธิภาพของเซิร์ฟเวอร์จะรุนแรงกว่ามากในฝั่ง response DTO สุดท้าย เวลาทำการทดลองเบนช์มาร์กแบบนี้ ไม่ควรใช้ DTO แค่ตัวเดียว แต่ควรทดลองกับหลายประเภทที่หลากหลายในความเป็นจริง เมื่อไม่มี DB I/O และมีการทดลองกับ DTO ที่มีโครงสร้างหลากหลาย ผลลัพธ์ก็จะแตกต่างกัน
ตั้งแต่แรกก็ดูเหมือนว่าฝั่งการเชื่อมต่อกับฐานข้อมูลน่าจะเป็นคอขวดอยู่แล้ว เลยรู้สึกว่าประเด็นที่หยิบมาพูดอาจจะตั้งผิดหรือเปล่า
ดูเหมือนจะถูกทำให้ดูราวกับว่ามีการปรับปรุงประสิทธิภาพทั้งที่จริง ๆ แล้วไม่ได้มี แต่ความจริงคือตั้งแต่แรกฝั่งฐานข้อมูลต่างหากที่เป็นคอขวด ผมเลยคิดว่าการเขียนโดยเน้นปรับปรุงจุดที่ไม่ใช่คอขวดอาจทำให้เกิดความเข้าใจผิดได้
ในสภาพแวดล้อมส่วนใหญ่ การปรับปรุงประสิทธิภาพหมายถึงการแก้คอขวด เมื่อจะปรับแต่งการตรวจสอบความถูกต้อง ก็ควรเป็นหลังจากระบุได้แล้วว่าฝั่งการตรวจสอบความถูกต้องคือคอขวด