การศึกษาประสิทธิภาพล่าสุดได้จุดประกายการอภิปรายเกี่ยวกับเทคโนโลยี Common Gateway Interface ( CGI ) อีกครั้ง พร้อมผลลัพธ์ที่น่าประหลาดใจซึ่งท้าทายสมมติฐานทั่วไปเกี่ยวกับแนวทางการพัฒนาเว็บ การทดสอบได้ทดลองภาษาโปรแกรมมิ่งต่างๆ ที่รันสคริปต์ CGI บนเซิร์ฟเวอร์ AMD 60 คอร์ เผยให้เห็นความแตกต่างของประสิทธิภาพอย่างมีนัยสำคัญและจุดประกายการถกเถียงว่าเทคโนโลยีเก่าควรได้รับการพิจารณาใหม่หรือไม่
 |
|---|
| ภาพรวมของการใช้เทคโนโลยี CGI กับ Rust สำหรับคำขอเว็บประสิทธิภาพสูง โดยเน้นความเกี่ยวข้องอย่างต่อเนื่องของเทคโนโลยีเก่าในการพัฒนาเว็บสมัยใหม่ |
ผลประสิทธิภาพเผยให้เห็นลำดับชั้นของภาษาอย่างชัดเจน
ผลการทดสอบแสดงให้เห็นความแปรปรวนของประสิทธิภาพอย่างมากระหว่างภาษาโปรแกรมมิ่งต่างๆ ภาษาที่คอมไพล์แล้วครองตำแหน่งนำในชาร์ตประสิทธิภาพ โดย C นำหน้าที่ประมาณ 5,800 คำขอต่อวินาที ตามมาด้วย Rust อย่างใกล้ชิดที่ 5,700 คำขอต่อวินาที Go ทำได้ 3,400 คำขอต่อวินาทีแม้จะมี overhead ในการเริ่มต้น runtime ในหมู่ภาษาที่ตีความ Python จัดการได้ 700 คำขอต่อวินาที ขณะที่ JavaScript กับ Node.js ทำให้หลายคนประหลาดใจด้วยการทำได้ 600 คำขอต่อวินาที Perl ส่งมอบ 500 คำขอต่อวินาที และสคริปต์ Bash แทบจะจัดการได้เพียง 40 คำขอต่อวินาทีขณะที่ใช้ทรัพยากร CPU ทั้งหมดที่มี
CGI (Common Gateway Interface): โปรโตคอลมาตรฐานที่อนุญาตให้เว็บเซิร์ฟเวอร์เรียกใช้โปรแกรมและส่งคืนผลลัพธ์เป็นหน้าเว็บ
ผลการทดสอบประสิทธิภาพ CGI (คำขอต่อวินาที)
| ภาษาโปรแกรม | ประสิทธิภาพ | หมายเหตุ |
|---|---|---|
| C | ~5,800 req/s | ประสิทธิภาพสูงสุด |
| Rust | ~5,700 req/s | ประสิทธิภาพใกล้เคียงกับ C มาก |
| Go | ~3,400 req/s | แม้จะมี overhead จากการเริ่มต้น runtime |
| Python | ~700 req/s | น่าพอใจสำหรับภาษา interpreted |
| JavaScript ( Node.js ) | ~600 req/s | ประสิทธิภาพดีอย่างน่าประหลาดใจ |
| Perl | ~500 req/s | ประสิทธิภาพที่ดีของภาษา scripting |
| Bash | ~40 req/s | ใช้ CPU ทั้งหมดจนเต็มประสิทธิภาพ |
สภาพแวดล้อมการทดสอบ: เครื่องเสมือน 60 VCPU ที่ใช้ AMD Genoa พร้อม RAM 240 GB
ชุมชนถกเถียงความซับซ้อนของการพัฒนาเว็บสมัยใหม่
ผลประสิทธิภาพได้จุดประกายการอภิปรายในวงกว้างเกี่ยวกับความซับซ้อนของการพัฒนาเว็บและการกลับมาสู่เทคโนโลยีที่เรียบง่าย นักพัฒนาหลายคนแสดงความผิดหวังต่อ JavaScript framework สมัยใหม่และ toolchain ที่เกี่ยวข้อง สมาชิกชุมชนคนหนึ่งสังเกตว่า ChatGPT ได้ฟื้นฟูความสนใจใน vanilla JavaScript และ jQuery โดยพบว่า mental overhead เบากว่ามากเมื่อเปรียบเทียบกับรูปแบบของ React อย่าง useCallback, useEffect และ useMemo ซึ่งพวกเขาเปรียบเทียบกับการจัดการหน่วยความจำด้วยตนเองในการเขียนโปรแกรม C
การอภิปรายขยายไปถึงสภาพแวดล้อมองค์กรที่นักพัฒนาสังเกตเห็นระบบที่มีการจัดสรรทรัพยากรมากเกินไป แอปพลิเคชันองค์กรมักต้องการทรัพยากรมหาศาลสำหรับงานที่ค่อนข้างง่าย โดยมีตัวอย่างหนึ่งอ้างถึงแอปพลิเคชันการตรวจสอบที่ใช้หน่วยความจำ 500MB ต่อระบบที่ตรวจสอบเพียงเพื่อ poll ข้อมูลทุกห้านาที
ความเกี่ยวข้องที่ไม่คาดคิดของ CGI ในการคำนวณสมัยใหม่
แม้จะถูกมองว่าล้าสมัย CGI กำลังพบผู้สนับสนุนใหม่ที่โต้แย้งว่าความเรียบง่ายของมันให้ข้อได้เปรียบในสถานการณ์เฉพาะ เทคโนโลยีนี้ให้การแยกกระบวนการอย่างสมบูรณ์ การทำความสะอาดหน่วยความจำอัตโนมัติ และขจัดความกังวลเกี่ยวกับการจัดการกระบวนการที่ทำงานอยู่นาน แต่ละคำขอทำงานในกระบวนการของตัวเอง ซึ่งจะสิ้นสุดหลังจากเสร็จสิ้น ป้องกัน memory leak และลดความเสี่ยงด้านความปลอดภัยระหว่างคำขอ
การมี isolated ephemeral request handler ที่ไม่มี shared state และไม่มี persistent runtime ทำให้เกิด programming model ที่สะอาดและดี
นักพัฒนาหลายคนเน้นประโยชน์ของ CGI สำหรับระบบฝังตัว เครื่องมือองค์กรภายใน และแอปพลิเคชันที่มีการเข้าชมน้อยซึ่ง overhead ของ framework สมัยใหม่ไม่คุ้มค่า แนวทางนี้ยังทำให้การ deployment ง่ายขึ้นเนื่องจาก executable ใหม่สามารถวางแทนที่ได้โดยไม่ต้องรีสตาร์ทบริการหรือการจัดการที่ซับซ้อน
การเปรียบเทียบ CGI กับการพัฒนาเว็บสมัยใหม่
ข้อดีของ CGI:
- การแยกกระบวนการอย่างสมบูรณ์ในแต่ละคำขอ
- การล้างหน่วยความจำอัตโนมัติเมื่อกระบวนการสิ้นสุด
- ไม่มีการแชร์สถานะระหว่างคำขอ
- การติดตั้งที่ง่าย (วางไฟล์ปฏิบัติการลงไปได้เลย)
- ไม่ต้องจัดการบริการ
- ไม่จำกัดภาษาโปรแกรม
ข้อเสียของ CGI:
- ค่าใช้จ่าย CPU สูงจากการดำเนินการ fork/exec
- ปัญหาการซิงโครไนซ์ที่อาจเกิดขึ้นกับทรัพยากรที่ใช้ร่วมกัน
- ข้อกังวลด้านความปลอดภัยแบบดั้งเดิมในการรันในไดเรกทอรีเอกสาร
- ไม่เหมาะสำหรับแอปพลิเคชันที่ต้องการประสิทธิภาพสูง
- จำกัดอยู่ที่โมเดลคำขอ/การตอบสนอง
ทางเลือกสมัยใหม่:
- FastCGI: กระบวนการถาวรที่มีอินเทอร์เฟซคล้าย CGI
- Reverse proxy กับ HTTP backends
- Serverless functions (โมเดลการทำงานคล้ายกัน)
- Microservices แบบ Container
ความท้าทายทางเทคนิคและการพิจารณาความปลอดภัย
การทดสอบเผยให้เห็นปัญหาทางเทคนิคบางอย่างที่มีอยู่ในการใช้งาน CGI เวอร์ชัน Rust มี time-of-check-to-time-of-use error ในการเริ่มต้นฐานข้อมูล แสดงให้เห็นว่า CGI สามารถแนะนำปัญหาการซิงโครไนซ์ขณะที่เอาเครื่องมือซิงโครไนซ์แบบดั้งเดิมออกไป ปัญหาดังกล่าวมักจะไม่เกิดขึ้นใน persistent application server ที่การตั้งค่าฐานข้อมูลเกิดขึ้นครั้งเดียวระหว่างการเริ่มต้น
การอภิปรายด้านความปลอดภัยมุ่งเน้นไปที่ชื่อเสียงทางประวัติศาสตร์ของ CGI เทียบกับคุณสมบัติความปลอดภัยจริง ในขณะที่หลายคนเชื่อมโยง CGI กับช่องโหว่เนื่องจากสคริปต์ที่เขียนไม่ดีจากทศวรรษ 1990 โปรโตคอลเองไม่ได้มีความปลอดภัยน้อยกว่าทางเลือกสมัยใหม่โดยธรรมชาติ อย่างไรก็ตาม แนวปฏิบัติแบบดั้งเดิมในการวางสคริปต์ที่สามารถเรียกใช้ได้ภายใน document root ของเว็บเซิร์ฟเวอร์สร้างช่องทางการโจมตีที่เป็นไปได้ โดยเฉพาะเมื่อรวมกับช่องโหว่การอัปโหลดไฟล์
การศึกษาประสิทธิภาพแสดงให้เห็นว่าแม้ CGI อาจไม่เหมาะสำหรับแอปพลิเคชันที่มีการเข้าชมสูงซึ่งต้องการหลายพันคำขอต่อวินาที แต่ยังคงเป็นตัวเลือกที่ใช้ได้สำหรับสถานการณ์จริงหลายกรณี ขณะที่นักพัฒนายังคงมองหาทางเลือกอื่นสำหรับ web stack สมัยใหม่ที่ซับซ้อน ความเรียบง่ายและความน่าเชื่อถือของ CGI ทำให้คุ้มค่าต่อการพิจารณาใหม่สำหรับกรณีการใช้งานที่เหมาะสม
อ้างอิง: Serving a half billion requests per day with Rust + CGI