PHP Configuration สำหรับเว็บไซต์ขนาดใหญ่: Apache Module vs FastCGI/FPM แบบไหนเหมาะสม?

FastCGI/FPM (PHP-FPM): โซลูชันสมัยใหม่

FastCGI/PHP-FPM เป็นวิธีใหม่กว่า ที่ Apache ไม่ได้รัน PHP โดยตรง แต่เป็นการส่งคำขอไปยังกระบวนการ PHP แยกต่างหาก (PHP-FPM daemon) Apache เพียงแต่ ส่งต่อคำขอ (proxy) เท่านั้น

ข้อดีของ FastCGI/FPM

• ความเสถียรสูงมาก – ถ้า PHP crash ได้ Apache ยังทำงานต่อไปได้ และสามารถเริ่มกระบวนการ PHP ใหม่โดยอัตโนมัติ ผู้ใช้บางคนจะได้ข้อผิดพลาด แต่ไม่ใช่เว็บไซต์ทั้งหมดที่ล้มลง
• ประสิทธิภาพดีกว่า – PHP-FPM ใช้ worker processes แบบพูล ซึ่งเมื่อใช้งานเสร็จแล้วจะถูกนำกลับมาใช้ใหม่ ไม่ต้องสร้างกระบวนการใหม่ทุกครั้ง นี่คือสาเหตุที่ FastCGI/FPM เร็วกว่า Apache Module
• ใช้ RAM ที่ประหยัด – เนื่องจาก PHP-FPM จัดการหน่วยความจำได้ดีกว่า และใช้ worker pool ของตัวเอง ไม่ต้องสร้างกระบวนการ Apache ใหม่ทั้งหมด
• ยืดหยุ่นมาก – คุณสามารถ reload PHP-FPM โดยไม่ต้อง restart Apache ได้ ไม่มีการหยุดบริการเลย
• ความปลอดภัยดีขึ้น – PHP-FPM สามารถรันด้วยบัญชีผู้ใช้ที่แตกต่างกัน (แยก user pool) ได้ ทำให้การแยก privilege ดีขึ้น
• ปรับแต่งได้อย่างละเอียด – คุณสามารถกำหนดจำนวน worker processes สูงสุด/ต่ำสุด ได้อย่างอิสระ ปรับตาม workload จริง

ข้อเสียและข้อควรระวัง

• ติดตั้งซับซ้อนกว่า – ต้องติดตั้ง Apache module mod_proxy_fcgi หรือ mod_proxy แล้วตั้งค่า virtual host ให้ proxy ไปยัง PHP-FPM ซึ่งมีหลายขั้นตอน
• ซิงโครไนซ์ระหว่างเซิร์ฟเวอร์ยาก – ถ้าคุณมีหลายเซิร์ฟเวอร์ การตั้งค่า PHP-FPM ให้เท่ากันบนทั้งหมดอาจจะยุ่งยาก (เวลาสเกล horizontally)
• ต้องมี tuning ที่ดี – ถ้าคุณไม่ปรับแต่งจำนวน worker processes ให้เหมาะสม PHP-FPM อาจสร้างกระบวนการมากเกินไป และใช้ RAM หรือ CPU มากถึงชาร์জ
• ความเสี่ยงเรื่องการสื่อสาร – Apache และ PHP-FPM ต้องสื่อสารผ่าน socket (TCP หรือ Unix socket) นี่คือจุดล้มเหลวที่มีศักยภาพ ถ้า socket ล่มลง

เปรียบเทียบด้านต่างๆ อย่างละเอียด

1. ประสิทธิภาพและความเร็ว

Apache Module ต่างมาก Apache ต้องสร้างกระบวนการใหม่สำหรับแต่ละการเชื่อมต่อ ดังนั้นกับเว็บไซต์ที่มีการเข้าชมสูง ระบบจะเต็มไปด้วยกระบวนการ Apache ที่พร้อมรอ ผลคือ CPU spike, context switching จำนวนมาก, และเวลาตอบสนองที่นาน

FastCGI/FPM มีประสิทธิภาพดีกว่า เนื่องจาก worker process ถูกนำกลับมาใช้ใหม่ ไม่มีการสร้างกระบวนการใหม่อย่างต่อเนื่อง นอกจากนี้ PHP-FPM อนุญาตให้คุณ ปรับจำนวน worker ให้เหมาะสมกับ CPU cores ของคุณ ทำให้ CPU ใช้งานได้อย่างมีประสิทธิภาพ

2. การใช้ทรัพยากร (RAM, CPU)

Apache Module ใช้ RAM มากมายเพราะกระบวนการ Apache แต่ละตัวมีอิมเมจความทรงจำเต็มไปด้วย Apache และ PHP runtime ทำให้กับเซิร์ฟเวอร์ธรรมชาติสูง หากใช้ Prefork MPM เซิร์ฟเวอร์ 4GB อาจรองรับ 150-200 การเชื่อมต่อพร้อมกันเท่านั้น

FastCGI/FPM ประหยัดกว่า Apache เพียงแต่ส่งคำขอ ไม่ต้องรอ PHP-FPM daemon จัดการเอง ด้วยความเต็มอิม 4GB เซิร์ฟเวอร์อาจรองรับ 300-500 การเชื่อมต่อได้

3. ความเสถียรและ Failover

Apache Module หากมี PHP error ร้ายแรง (segmentation fault, infinite loop) ทั้งกระบวนการ Apache ล้มลง ผลอื่นๆ ก็ได้รับผลกระทบ ผู้ใช้ที่เชื่อมต่อในขณะนั้นอาจเห็น 500 error

FastCGI/FPM ดีกว่า PHP-FPM crash ได้ Apache ยังทำงานต่อไป PHP-FPM daemon สามารถ auto-restart ได้ (ถ้าคุณตั้งค่า systemd หรือ supervisor) เพียงแค่ผู้ใช้บางคนจะเห็น 503 error แต่ไม่ใช่เว็บไซต์ทั้งหมด

4. ความปลอดภัย

Apache Module ไม่ดี เนื่องจาก PHP รันเป็นผู้ใช้เดียวกันกับ Apache (มักเป็น www-data) ถ้ามี security vulnerability ใน PHP หรือใน plugin/extension เมื่อมีการโจมตี ผู้โจมตีสามารถเข้าถึงไฟล์ทั้งหมดที่ www-data อ่านได้ ถ้ามี virtual host หลายตัว (multi-tenant) ปัญหานี้จะแย่ลง

FastCGI/FPM เหนือกว่า FPM pool สามารถรันด้วยผู้ใช้ที่แตกต่างกัน (เช่น www-domain1, www-domain2) ได้ ทำให้ถ้าเว็บไซต์หนึ่ง compromised อีกเว็บไซต์หนึ่งจะไม่ได้รับผล นี่เป็นข้อดีใหญ่ที่สำหรับเว็บไซต์ขนาดใหญ่หรือ multi-tenant hosting

5. ความยืดหยุ่นในการอัปเดต

Apache Module หากต้องการอัปเดต php.ini หรือ reload PHP บน production คุณต้องรัน sudo systemctl restart apache2 ซึ่ง จะหยุดบริการชั่วขณะ (downtime) บนเว็บไซต์ทั้งหมด

FastCGI/FPM ปรับแต่งได้ดีกว่า sudo systemctl reload php-fpm จะ reload gracefully โดยกระบวนการเดิมให้บริการคำขอที่เหลือจนเสร็จ แล้วสร้างกระบวนการใหม่ ไม่มีการหยุดบริการ

ข้อเตือนสำคัญที่ต้องหลีกเลี่ยง

การอัปปรับแต่งที่ผิด

ถ้าใช้ FastCGI/FPM ตั้งค่า pm.max_children (จำนวน worker process) สูงเกินไป อาจเกิด out-of-memory (OOM) และเซิร์ฟเวอร์ก็จะ freeze ให้นับว่า CPU cores × 2-3 เป็นจุดเริ่มต้นที่ดี ถ้าต้องการสูงกว่านั้นต้องทำ load test จริงๆ

ไม่ติดตั้ง Monitoring

ไม่ว่าเลือก Apache Module หรือ FastCGI/FPM ต้อง monitor process memory, CPU, และ status ของ PHP daemon อย่างใกล้ชิด ถ้าไม่มี alert system ปัญหาอาจแพร่ระบาดเพราะคุณไม่รู้

ความเสี่ยงจาก Memory Leak ใน PHP Script

ถ้า script PHP ของคุณมี memory leak (เช่น loop ที่ allocate memory แต่ไม่ free) หลังจากทำงานหลายครั้ง worker process ก็จะใช้ RAM เพิ่มขึ้น FastCGI/FPM มี feature pm.max_requests ที่บังคับให้ worker restart หลังจากจำนวนคำขอที่กำหนด ต้องตั้งค่านี้อย่างสมควร

Unix Socket vs TCP Socket

เมื่อตั้ง FastCGI/FPM ต้องเลือก Unix socket (/run/php/php-fpm.sock) มากกว่า TCP socket (localhost:9000) Unix socket เร็วกว่า ปลอดภัยกว่า และไม่มีความเสี่ยง port collision

สถานการณ์จริง: เมื่อไหร่ควรเลือกอะไร

เลือก Apache Module ถ้า:

• คุณใช้ shared hosting ที่ provider ตั้งค่าให้แล้ว ไม่ต้องปรับแต่ง
• เว็บไซต์เล็กๆ traffic ต่ำ (ผู้เข้าชมพร้อมกัน < 50 คน)
• ใช้ .htaccess ที่มี rewrite rules ซับซ้อน (บางครั้ง FastCGI มีข้อ edge case)
• อาศัยฟีเจอร์ Apache หลายอย่าง (mod_rewrite, mod_ssl เป็นต้น)

เลือก FastCGI/FPM ถ้า:

• เว็บไซต์ขนาดใหญ่ ที่คาดว่า traffic สูง (ผู้เข้าชมพร้อมกัน > 100 คน)
• ต้องการ uptime สูง เพราะต้อง graceful reload โดยไม่มี downtime
• ต้อง แยก privilege ระหว่างเว็บไซต์เพราะด้านความปลอดภัย
• ต้องการให้ PHP-FPM และ Apache scale อิสระ (เช่นย้ายไปใช้ nginx ในอนาคต)
• ต้องการ ความเสถียรสูง PHP crash ต้องไม่หยุดเว็บไซต์อื่น
• ต้องการปรับแต่ง php.ini บ่อยๆ โดยไม่มี downtime

ตัวอย่างการตั้งค่า FastCGI/FPM พื้นฐาน

หากตัดสินใจใช้ FastCGI/FPM นี่คือขั้นตอนพื้นฐาน:

1. ติดตั้ง PHP-FPM

• sudo apt install php-fpm

2. เปิดใช้งาน Apache modules ที่จำเป็น

• sudo a2enmod proxy
• sudo a2enmod proxy_fcgi
• sudo a2enmod setenvif

3. ตั้งค่า Virtual Host ให้ proxy ไปยัง PHP-FPM ใน /etc/apache2/sites-available/yourdomain.conf เพิ่ม:

<FilesMatch \.php$>
  SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost/"
</FilesMatch>

4. ปรับแต่ง PHP-FPM pool ใน /etc/php/7.4/fpm/pool.d/www.conf:

• pm = dynamic (ปรับจำนวน worker โดยอัตโนมัติ)
• pm.min_spare_servers = 5
• pm.max_spare_servers = 35
• pm.max_children = 50 (ปรับตามสมดุลของ RAM และ CPU)
• pm.max_requests = 500 (restart worker หลังจาก 500 request เพื่อหลีกเลี่ยง memory leak)

5. Reload และ test

• sudo systemctl reload apache2
• sudo systemctl reload php7.4-fpm

ตรวจสอบด้วย php -v และเข้าเว็บไซต์ดู

ความเสี่ยงที่มักมองข้าม

ต้องระวังจากการตั้งค่าที่ดูปกติแต่เป็นจุดล้มเหลว: ถ้า Unix socket เสื่อมหรือหาย Apache ไม่สามารถติดต่อ PHP-FPM ได้ ผู้ใช้ก็จะเห็น 503 error ทั้งหมด ตรวจสอบสิทธิการเข้าถึง socket ด้วย ls -l /run/php/php-fpm.sock ต้องให้ Apache read/write ได้

นอกจากนี้ timeout setting ก็ส่งผลใหญ่ ถ้า PHP script ทำงานนาน (เช่น 30 วินาที) แต่ request_terminate_timeout ตั้งเพียง 5 วินาที PHP-FPM จะ kill process ทำให้ผู้ใช้ได้ response ที่ไม่สมบูรณ์

สรุป: ตัดสินใจอย่างชาญฉลาด

Apache Module มีความสำคัญเชิงประวัติศาสตร์ ติดตั้งง่าย แต่ ไม่เหมาะสำหรับเว็บไซต์ขนาดใหญ่ ที่ต้องการประสิทธิภาพ ความเสถียร และความปลอดภัยสูง

FastCGI/FPM เป็นตัวเลือกที่ดีกว่าสำหรับสถานการณ์หลายๆ อย่าง—ถ้าคุณสามารถลงมือทำ tuning ที่ดี monitor ที่เพียงพอ และเข้าใจข้อเสี่ยง ผลตอบแทนจะเห็นผลอย่างชัดเจน ทั้งในด้าน response time, resource usage, และ uptime

ความจริงคือไม่มีตัวเลือก "ถูกต้อง" แบบสัมบูรณ์ ขึ้นอยู่กับความต้องการของคุณ หากเป็นเว็บไซต์ production ที่ต้องการความเสถียร FastCGI/FPM น่าจะเป็นทางเลือกที่ดี ส่วน Apache Module ใช้เมื่อความสะดวกสบายมีความสำคัญกว่าอื่นทั้งหมด

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