วิธีการที่ก่อให้เกิดข้อโต้แย้งในการรัน WordPress ทั้งหมดจากหน่วยความจำ RAM ได้จุดประกายการอภิปรายอย่างร้อนแรงในชุมชนนักพัฒนา โดยผู้วิจารณ์ตั้งคำถามถึงทั้งประโยชน์ในทางปฏิบัติและวิธีการนำไปใช้ของผู้เขียน วิธีการซึ่งเกี่ยวข้องกับการเก็บไฟล์ WordPress และฐานข้อมูล MariaDB ไว้ในระบบไฟล์หน่วยความจำชั่วคราว (temporary memory filesystems) สัญญาว่าจะให้ความเร็วที่สูงลิ่ว แต่ก็ทำให้เกิดความกังวลอย่างมีนัยสำคัญเกี่ยวกับความทนทานของข้อมูลและผลประโยชน์ด้านประสิทธิภาพในโลกแห่งความเป็นจริง
 |
|---|
| สำรวจแนวทางที่ก้าวล้ำในการเพิ่มประสิทธิภาพ WordPress ด้วยการรันทั้งหมดจาก RAM |
ข้อเรียกร้องด้านประสิทธิภาพอยู่ภายใต้การตรวจสอบ
หลักการพื้นฐานของการรัน WordPress จาก RAM อยู่ที่การขจัดจุดติดขัดของการอ่านเขียนดิสก์ I/O แต่สมาชิกในชุมชนก็ระบุจุดบกพร่องที่อาจเกิดขึ้นในแนวทางนี้ได้อย่างรวดเร็ว ผู้แสดงความคิดเห็นหลายคนตั้งข้อสังเกตว่าการกำหนดค่าเซิร์ฟเวอร์สมัยใหม่มีกลไกการแคชที่ซับซ้อนอยู่แล้วซึ่งเก็บข้อมูลที่เข้าถึงบ่อยๆ ไว้ในหน่วยความจำ
PHP Opcache โหลดและคอมไพล์ไฟล์ php ทั้งหมดลงใน ram อยู่แล้ว โดยจะเกิดขึ้นเพียงครั้งเดียว MySQL / MariaDB ก็มีการแคช ram มากมายเช่นกัน - พวกเขาไม่ได้นั่งอยู่แต่เฉยๆ มานานหลายทศวรรษ ผู้แสดงความคิดเห็นหนึ่งรายระบุ
สิ่งนี้ชี้ให้เห็นว่าวิธีการแคชแบบดั้งเดิมอาจให้ผลประโยชน์ด้านประสิทธิภาพที่ใกล้เคียงกันโดยไม่มีความเสี่ยงเรื่องความคงอยู่ของข้อมูล การอภิปรายเปิดเผยว่านักพัฒนาหลายคนสามารถทำคะแนน PageSpeed ได้อย่างยอดเยี่ยม (บางรายรายงาน 96-97) โดยใช้ปลั๊กอินแคชแบบดั้งเดิมและการกำหนดค่าเซิร์ฟเวอร์ที่เหมาะสม ทำให้เกิดคำถามว่าวิธีการแบบ RAM ที่รุนแรงนี้ให้ข้อได้เปรียบที่มีความหมายเหนือการตั้งค่าแบบดั้งเดิมที่ปรับแต่งอย่างดีแล้วหรือไม่
คะแนน PageSpeed ที่รายงาน:
- เว็บไซต์ที่ปรับแต่ง RAM ของผู้เขียน: 72
- เว็บไซต์ WordPress แบบทั่วไปที่มี caching: 83-97
- เว็บไซต์ที่ปรับแต่งอย่างดีด้วย WP Super Cache: สูงสุดถึง 97
ความกังวลเรื่องความทนทานของข้อมูลปรากฏขึ้น
คำวิจารณ์ที่สำคัญที่สุดมุ่งเน้นไปที่วิธีการจัดการความคงอยู่ของฐานข้อมูลของวิธีนี้ การรัน MariaDB ทั้งหมดใน tmpfs จะทำให้การเปลี่ยนแปลงฐานข้อมูลทั้งหมดหายไประหว่างการรีบูตเซิร์ฟเวอร์หรือระบบขัดข้อง เว้นแต่จะมีการสำรองข้อมูลอย่างเหมาะสม แนวทางนี้ทำให้เกิดการเปรียบเทียบกับ MongoDB รุ่นแรกๆ ที่ให้ความสำคัญกับความเร็วกว่าความปลอดภัยของข้อมูล
ผู้แสดงความคิดเห็นหลายคนแสดงความสงสัยเกี่ยวกับการนำไปใช้ในทางปฏิบัติ คุณไม่ควรย้ายไดเรกทอรีข้อมูล (datadir) ทั้งหมดของ MariaDB ไปที่ tmpfs และทิ้งความทนทานไป นักพัฒนาหนึ่งรายระบุ พร้อมเน้นย้ำว่าการกำหนดค่าฐานข้อมูลแบบดั้งเดิมสามารถปรับแต่งเพื่อประสิทธิภาพได้ ในขณะที่ยังคงความสมบูรณ์ของข้อมูลผ่านการกำหนดขนาดบัฟเฟอร์พูล (buffer pool) และการบันทึกธุรกรรม (transaction logging) ที่เหมาะสม
ปัญหาการเข้าถึงบั่นทอนความน่าเชื่อถือ
ที่สะท้อนกลับอย่างน่าขัน เว็บไซต์ของผู้เขียนเองกลายเป็นจุดโต้แย้งเมื่อผู้ใช้จำนวนมากรายงานว่าถูกบล็อกโดยบริการความปลอดภัยของ Cloudflare ผู้ใช้จากเยอรมนี บราซิล และที่ตั้งอื่นๆ พบว่าตนเองไม่สามารถเข้าถึงไซต์ได้ โดยมีข้อความระบุว่าพวกเขาถูกบล็อกโดยบริการความปลอดภัยที่ปกป้อง rickconlee.com
การบล็อกดูเหมือนจะส่งผลกระทบต่อผู้ใช้จากเบราว์เซอร์และผู้ให้บริการเครือข่ายที่แตกต่างกัน โดยผู้ใช้จากเยอรมนีรายหนึ่งระบุว่า: ทั้ง Safari บนเดสก์ท็อปและมือถือ รุ่นมาตรฐาน ทั้งผ่านเคเบิลและ 5G ถูกบล็อกทั้งหมด ปัญหาการเข้าถึงนี้บั่นทอนความน่าเชื่อถือของผู้เขียน โดยเฉพาะอย่างยิ่งเมื่อรายงานว่าคะแนน PageSpeed ของไซต์ต่ำกว่าการติดตั้ง WordPress ที่กำหนดค่าแบบดั้งเดิมจำนวนมาก
มีการเสนอวิธีแก้ไขทางเลือก
การอภิปรายในชุมชนเปิดเผยทางเลือกที่เรียบง่ายกว่าหลายประการสำหรับการบรรลุประสิทธิภาพสูงโดยไม่มีความซับซ้อนของการปรับใช้แบบ RAM ทั้งหมด ผู้แสดงความคิดเห็นหลายคนแนะนำให้ใช้การแคชรีเวิร์สพร็อกซี่ (reverse proxy caching), การแคช NGINX fastcgi หรือการตั้งค่า CDN ที่กำหนดค่าได้อย่างเหมาะสม เป็นแนวทางที่ปฏิบัติได้จริงมากกว่า
นักพัฒนาหนึ่งรายตั้งข้อสังเกตว่า Cloudflare จริงๆ แล้วไม่ได้แคชเนื้อหา HTML ของไซต์ (cf-cache-status: DYNAMIC) ชี้ให้เห็นว่าการปรับปรุงการกำหนดค่า CDN พื้นฐานสามารถให้ผลประโยชน์ด้านประสิทธิภาพที่สำคัญได้ คนอื่นๆ ชี้ให้เห็นว่าเว็บไซต์ขนาดเล็กมักประสบปัญหาการเริ่มต้นระบบเย็น (cold start problems) ซึ่งสามารถแก้ไขได้ผ่านกลยุทธ์การแคชที่เรียบง่ายกว่า แทนที่จะเป็นการปรับใช้แบบ RAM ทั้งหมด
ทางเลือกอื่นที่ได้รับการกล่าวถึงบ่อย:
- PHP OPcache สำหรับไฟล์ PHP ที่คอมไพล์แล้วใน RAM
- MariaDB innodb_buffer_pool สำหรับแคชฐานข้อมูล
- NGINX fastcgi cache สำหรับเนื้อหาแบบคงที่
- ปลั๊กอิน WP Super Cache พร้อมไซต์คงที่ที่บีบอัดด้วย gzip ล่วงหน้า
- การกำหนดค่า CDN ที่เหมาะสมด้วยการแคชหน้าเว็บของ Cloudflare
คำถามเกี่ยวกับการนำไปใช้ทางเทคนิค
เหนือกว่าความกังวลด้านแนวคิดแล้ว ผู้แสดงความคิดเห็นยังตั้งคำถามถึงข้อเรียกร้องทางเทคนิคเฉพาะในบทความ บางคนสงสัยว่า tmpfs ขจัดการตรวจสอบสิทธิ์ของระบบไฟล์ (filesystem permission checks) อย่างที่อ้างจริงหรือไม่ ในขณะที่คนอื่นๆ ตั้งข้อสังเกตว่าแนวทางที่อธิบายไว้ดูเหมือนจะซับซ้อนเกินความจำเป็นเมื่อเทียบกับการเพียงแค่คัดลอกไฟล์ไปที่ /dev/shm
การอภิปรายยัง касаетсяว่าผลประโยชน์ด้านประสิทธิภาพจะสังเกตเห็นได้ในสถานการณ์จริงหรือไม่ เนื่องจากที่เก็บข้อมูล NVMe สมัยใหม่มีเวลาแฝงต่ำมากอยู่แล้วสำหรับแอปพลิเคชันเว็บส่วนใหญ่ ผู้แสดงความคิดเห็นหลายคนขอการเปรียบเทียบประสิทธิภาพก่อนและหลัง ซึ่งขาดหายไปอย่างเห็นได้ชัดจากบทความต้นฉบับ
ข้อกังวลด้านเทคนิคที่ระบุ:
- ความเสี่ยงในการสูญเสียข้อมูลกับ MariaDB ใน tmpfs
- การตรวจสอบสิทธิ์ของระบบไฟล์ยังคงเกิดขึ้นใน tmpfs
- ปัญหาการเริ่มต้นช้าสำหรับเว็บไซต์ขนาดเล็ก
- ปัญหาการกำหนดค่า Cloudflare (สถานะแคช DYNAMIC)
- ขาดการเปรียบเทียบประสิทธิภาพก่อนและหลัง
บทสรุป
วิธีการ WordPress แบบ RAM เป็นตัวแทนของแนวทางสุดขั้วในการเพิ่มประสิทธิภาพที่ทำให้ชุมชนนักพัฒนาแตกออกเป็นสองฝ่าย แม้ว่าแนวคิดของการขจัดจุดติดขัด disk I/O จะถูกต้องตามหลักทฤษฎี แต่ความกังวลในการนำไปใช้จริง ความเสี่ยงด้านความทนทานของข้อมูล และคำถามเกี่ยวกับประโยชน์ในโลกแห่งความจริง ได้ลดความกระตือรือร้นต่อแนวทางที่รุนแรงนี้ลง การอภิปรายเน้นย้ำว่าบางครั้งวิธีแก้ปัญหาที่มีประสิทธิภาพที่สุดไม่ใช่สิ่งที่ดราม่าที่สุด แต่เป็นการปรับแต่งอย่างระมัดระวังของเทคโนโลยีที่มีอยู่และได้รับการพิสูจน์แล้ว ดังที่ผู้แสดงความคิดเห็นหนึ่งรายกล่าวอย่างรวบรัดว่า บางครั้งวิธีที่ดีที่สุดคือการคัดลอกทุกอย่างไปที่ /dev/shm ก่อนเปิดตัว แล้วก็จบ - ยอมรับคุณค่าของการแคช RAM โดยไม่ทำให้การแก้ปัญหาซับซ้อนเกินไป