การเพิ่มประสิทธิภาพ PHP-FPM เพื่อประสิทธิภาพสูงสุด

PHP มีอยู่ทุกหนทุกแห่งและเป็นภาษาที่ใช้กันอย่างแพร่หลายมากที่สุดบนอินเทอร์เน็ตเว็บ.


อย่างไรก็ตามมันไม่เป็นที่รู้จักอย่างแน่นอนสำหรับความสามารถประสิทธิภาพสูงโดยเฉพาะอย่างยิ่งเมื่อมันมาถึงระบบพร้อมกันสูง และนั่นคือเหตุผลที่สำหรับกรณีการใช้งานเฉพาะเช่นภาษาเช่นโหนด (ใช่ฉันรู้ว่ามันไม่ใช่ภาษา) Go และ Elixir กำลังเข้ายึดครอง.

ที่กล่าวมามีจำนวนมากที่คุณสามารถทำได้เพื่อปรับปรุงประสิทธิภาพ PHP บนเซิร์ฟเวอร์ของคุณ บทความนี้มุ่งเน้นไปที่สิ่งที่ php-fpm ซึ่งเป็นวิธีที่เป็นธรรมชาติในการกำหนดค่าบนเซิร์ฟเวอร์ของคุณหากคุณใช้ Nginx.

ในกรณีที่คุณรู้ว่า php-fpm คืออะไรคุณสามารถข้ามไปยังส่วนที่เกี่ยวกับการปรับให้เหมาะสม.

php-fpm คืออะไร?

มีนักพัฒนาไม่กี่คนที่สนใจ DevOps ด้านข้างของสิ่งต่าง ๆ และแม้แต่ในหมู่ผู้ที่ทำสิ่งเล็ก ๆ น้อย ๆ ก็รู้ว่าเกิดอะไรขึ้นภายใต้ประทุน น่าสนใจเมื่อเบราว์เซอร์ส่งคำขอไปยังเซิร์ฟเวอร์ที่ใช้ PHP ไม่ใช่ PHP ที่เป็นจุดติดต่อแรก แต่เป็นเซิร์ฟเวอร์ HTTP หลัก ๆ คือ Apache และ Nginx “ เว็บเซิร์ฟเวอร์” เหล่านี้จะต้องตัดสินใจว่าจะเชื่อมต่อกับ PHP และส่งต่อคำขอประเภทข้อมูลและส่วนหัวไปที่ใด.

รอบการตอบสนองคำขอในกรณีของ PHP (เครดิตรูปภาพ: ProinerTech)

ในแอปพลิเคชั่น PHP รุ่นใหม่ส่วน “ค้นหาไฟล์” ด้านบนคือ index.php ซึ่งเซิร์ฟเวอร์ได้รับการกำหนดค่าให้มอบหมายการร้องขอทั้งหมดไปยัง.

ตอนนี้เว็บเซิร์ฟเวอร์เชื่อมต่อกับ PHP ได้พัฒนาไปอย่างตรงไหนและบทความนี้จะขยายออกไปถ้าเราเข้าสู่ทุกสิ่ง แต่พูดโดยคร่าวๆในช่วงเวลาที่ Apache เป็นเว็บเซิร์ฟเวอร์ที่เลือก PHP เป็นโมดูลที่รวมอยู่ในเซิร์ฟเวอร์.

ดังนั้นเมื่อใดก็ตามที่ได้รับการร้องขอเซิร์ฟเวอร์จะเริ่มกระบวนการใหม่ซึ่งจะรวม PHP โดยอัตโนมัติและทำการดำเนินการ วิธีนี้เรียกว่า mod_php ย่อมาจาก“ php เป็นโมดูล” วิธีนี้มีข้อ จำกัด ซึ่ง Nginx เอาชนะด้วย php-fpm.

ใน php-fpm ความรับผิดชอบของการจัดการ PHP, โพรเซสอยู่กับโปรแกรม PHP ภายในเซิร์ฟเวอร์ กล่าวอีกนัยหนึ่งคือเว็บเซิร์ฟเวอร์ (Nginx ในกรณีของเรา) ไม่สนใจว่า PHP นั้นอยู่ที่ใดและจะโหลดอย่างไรตราบใดที่รู้วิธีการส่งและรับข้อมูลจากมัน หากคุณต้องการคุณสามารถคิดถึง PHP ในกรณีนี้เป็นเซิร์ฟเวอร์อื่นในตัวเองซึ่งจัดการกระบวนการ PHP ลูกบางอย่างสำหรับการร้องขอขาเข้า (ดังนั้นเรามีคำขอถึงเซิร์ฟเวอร์ซึ่งเซิร์ฟเวอร์ได้รับและส่งต่อไปยังเซิร์ฟเวอร์ – ค่อนข้างบ้า! :-P).

หากคุณตั้งค่า Nginx เสร็จแล้วหรือแม้แต่ลองสอดส่องพวกเขาคุณจะเจอสิ่งนี้:

ตำแหน่ง ~ \ .php $ {
try_files $ uri = 404;
fastcgi_split_path_info ^ (. + \. php) (/.+) $;
fastcgi_pass unix: /run/php/php7.2-fpm.sock;
fastcgi_index index.php;
รวม fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;
}

บรรทัดที่เราสนใจคือ: fastcgi_pass unix: /run/php/php7.2-fpm.sock; ซึ่งบอกให้ Nginx สื่อสารกับกระบวนการ PHP ผ่านซ็อกเก็ตชื่อ php7.2-fpm.sock ดังนั้นสำหรับทุกคำขอที่เข้ามา Nginx เขียนข้อมูลผ่านไฟล์นี้และเมื่อได้รับผลลัพธ์ให้ส่งกลับไปยังเบราว์เซอร์.

ฉันต้องย้ำอีกครั้งว่านี่ไม่ใช่ภาพที่สมบูรณ์ที่สุดหรือถูกต้องที่สุดว่าเกิดอะไรขึ้น แต่มันแม่นยำสำหรับงาน DevOps ส่วนใหญ่.

นอกจากนั้นให้สรุปสิ่งที่เราได้เรียนรู้มา:

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

หรือกราฟิก:

PHP และ Nginx ทำงานร่วมกันอย่างไร (เครดิตรูปภาพ: DataDog)

ยอดเยี่ยมจนถึงตอนนี้มาคำถามล้านดอลลาร์: อะไรคือ PHP-FPM?

ส่วน“ FPM” ใน PHP ย่อมาจาก“ Fast Process Manager” ซึ่งเป็นวิธีแฟนซีในการบอกว่า PHP ที่ทำงานบนเซิร์ฟเวอร์ไม่ใช่กระบวนการเดียว แต่เป็นกระบวนการ PHP บางอย่างที่ถูกวางไข่ควบคุมและฆ่า ปิดโดยตัวจัดการกระบวนการ FPM นี้ มันเป็นตัวจัดการกระบวนการนี้ที่เว็บเซิร์ฟเวอร์ส่งการร้องขอไปยัง.

PHP-FPM เป็นหลุมกระต่ายทั้งหมดในตัวเองดังนั้นโปรดสำรวจถ้าคุณต้องการ แต่สำหรับวัตถุประสงค์ของเราคำอธิบายมากมายนี้จะทำ ��

ทำไมปรับ php-fpm?

เหตุใดจึงต้องกังวลเกี่ยวกับการเต้นรำทั้งหมดนี้เมื่อสิ่งต่าง ๆ ใช้งานได้ดี? ทำไมไม่เพียงแค่ทิ้งสิ่งต่าง ๆ ตามที่เป็นอยู่.

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

อีกสิ่งที่ควรตระหนักคือ Nginx ถูกสร้างขึ้นเพื่อจัดการปริมาณงานจำนวนมาก มันสามารถจัดการการเชื่อมต่อนับพันในเวลาเดียวกัน แต่ถ้าไม่เหมือนกันกับการติดตั้ง PHP ของคุณคุณกำลังจะเสียทรัพยากรเพราะ Nginx จะต้องรอให้ PHP เสร็จสิ้นกระบวนการปัจจุบันและยอมรับ จากนั้นลบข้อดีใด ๆ ที่ Nginx ถูกสร้างขึ้นเพื่อนำเสนอโดยสังเขป!

ดังนั้นเมื่อมองไปทางอื่นเราจะมาดูกันว่าเราจะเปลี่ยนแปลงอะไรเมื่อพยายามเพิ่มประสิทธิภาพ php-fpm.

วิธีเพิ่มประสิทธิภาพ PHP-FPM?

ตำแหน่งไฟล์การกำหนดค่าสำหรับ php-fpm อาจแตกต่างกันบนเซิร์ฟเวอร์ดังนั้นคุณจะต้องทำการวิจัยเพื่อหาตำแหน่ง คุณสามารถใช้คำสั่งค้นหาถ้าบน UNIX บน Ubuntu ของฉันพา ธ คือ /etc/php/7.2/fpm/php-fpm.conf แน่นอนว่าเวอร์ชั่น 7.2 เป็นเวอร์ชันของ PHP ที่ฉันใช้งานอยู่.

นี่คือลักษณะของไฟล์สองสามบรรทัดแรก:

;;;;;;;;;;;;;;;;;;;;;
; การกำหนดค่า FPM;
;;;;;;;;;;;;;;;;;;;;;

; เส้นทางสัมพัทธ์ทั้งหมดในไฟล์กำหนดค่านี้สัมพันธ์กับการติดตั้งของ PHP
; คำนำหน้า (/ usr) คำนำหน้านี้สามารถเปลี่ยนแปลงได้แบบไดนามิกโดยใช้
; อาร์กิวเมนต์ ‘-p’ จากบรรทัดคำสั่ง.

;;;;;;;;;;;;;;;;;;
; ตัวเลือกสากล
;;;;;;;;;;;;;;;;;;

[โลก]
; ไฟล์ Pid
; หมายเหตุ: คำนำหน้าเริ่มต้นคือ / var
; ค่าเริ่มต้น: ไม่มี
pid = /run/php/php7.2-fpm.pid

; ไฟล์บันทึกข้อผิดพลาด
; หากตั้งไว้ที่ "syslog", บันทึกถูกส่งไปยัง syslogd แทนที่จะเขียน
; เป็นไฟล์ในเครื่อง.
; หมายเหตุ: คำนำหน้าเริ่มต้นคือ / var
; ค่าเริ่มต้น: log / php-fpm.log
error_log = /var/log/php7.2-fpm.log

ควรมีบางสิ่งที่ชัดเจนในทันที: line pid = /run/php/php7.2-fpm.pid บอกเราว่าไฟล์ใดมีรหัสกระบวนการของกระบวนการ php-fpm.

เรายังเห็นว่า /var/log/php7.2-fpm.log เป็นที่ที่ php-fpm กำลังจะจัดเก็บบันทึก.

ภายในไฟล์นี้เพิ่มตัวแปรอีกสามตัวดังนี้:

Emergency_restart_threshold 10
Emergency_restart_interval 1 ม
process_control_timeout 10 วินาที

การตั้งค่าสองรายการแรกนั้นเป็นการเตือนและกำลังบอกกระบวนการ php-fpm ว่าหากกระบวนการลูกสิบกระบวนการล้มเหลวภายในหนึ่งนาทีกระบวนการ php-fpm หลักควรเริ่มต้นใหม่เอง.

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

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

น่าแปลกที่นี่ไม่ใช่เนื้อของการกำหนดค่า php-fpm! นั่นเป็นเพราะการให้บริการคำขอเว็บ php-fpm สร้างกลุ่มกระบวนการใหม่ซึ่งจะมีการกำหนดค่าแยกต่างหาก ในกรณีของฉันชื่อพูลกลายเป็น www และไฟล์ที่ฉันต้องการแก้ไขคือ /etc/php/7.2/fpm/pool.d/www.conf.

มาดูกันว่าไฟล์นี้เริ่มเป็นอย่างไร:

; เริ่มพูลใหม่ที่ชื่อว่า ‘www’.
; ตัวแปร $ pool สามารถใช้ในคำสั่งใดก็ได้และจะถูกแทนที่ด้วย
; ชื่อพูล (‘www’ ที่นี่)
[www]

; ต่อคำนำหน้าพูล
; มันใช้เฉพาะในคำสั่งดังต่อไปนี้:
; – ‘access.log’
; – ‘ช้า’
; – ‘ฟัง’ (unixsocket)
; – ‘chroot’
; – ‘chdir’
; – ‘php_values’
; – ‘php_admin_values’
; เมื่อไม่ได้ตั้งค่าจะใช้คำนำหน้าส่วนกลาง (หรือ / usr) แทน.
; หมายเหตุ: คำสั่งนี้สามารถสัมพันธ์กับคำนำหน้าส่วนกลาง.
; ค่าเริ่มต้น: ไม่มี
; prefix = / path / to / pool / $ pool

; ผู้ใช้ Unix / กลุ่มของกระบวนการ
; หมายเหตุ: ผู้ใช้มีผลบังคับใช้ หากกลุ่มไม่ได้ตั้งค่ากลุ่มผู้ใช้เริ่มต้น
; จะถูกนำไปใช้.
user = www-data
group = www-data

การมองอย่างรวดเร็วที่ส่วนท้ายของตัวอย่างด้านบนจะไขปริศนาว่าทำไมกระบวนการเซิร์ฟเวอร์จึงทำงานเป็นข้อมูล www หากคุณพบปัญหาการอนุญาตให้ใช้ไฟล์เมื่อตั้งค่าเว็บไซต์ของคุณคุณอาจเปลี่ยนเจ้าของหรือกลุ่มของไดเรกทอรีเป็น www-data จึงทำให้กระบวนการ PHP สามารถเขียนลงในไฟล์บันทึกและอัปโหลดเอกสาร ฯลฯ.

ในที่สุดเราก็มาถึงแหล่งที่มาของเรื่องการตั้งค่าผู้จัดการกระบวนการ (pm) โดยทั่วไปคุณจะเห็นค่าเริ่มต้นเป็นดังนี้:

pm = ไดนามิก
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

ดังนั้นอะไร“พลวัต” ที่นี่หมายถึงอะไร ฉันคิดว่าเอกสารอย่างเป็นทางการอธิบายได้ดีที่สุด (ฉันหมายถึงนี่ควรเป็นส่วนหนึ่งของไฟล์ที่คุณกำลังแก้ไขอยู่ แต่ฉันทำซ้ำที่นี่ในกรณีที่ไม่ได้เป็น):

; เลือกวิธีที่ผู้จัดการกระบวนการจะควบคุมจำนวนกระบวนการลูก.
; ค่าที่เป็นไปได้:
; คงที่ – จำนวนคงที่ (pm.max_children) ของกระบวนการเด็ก;
; แบบไดนามิก – จำนวนของกระบวนการลูกมีการตั้งค่าแบบไดนามิกขึ้นอยู่กับ
; คำสั่งดังต่อไปนี้ ด้วยการจัดการกระบวนการนี้จะมี
; เด็กอย่างน้อยเสมอ 1.
; pm.max_children – จำนวนเด็กสูงสุดที่สามารถทำได้
; มีชีวิตอยู่ในเวลาเดียวกัน.
; pm.start_servers – จำนวนลูกที่สร้างเมื่อเริ่มต้น.
; pm.min_spare_servers – จำนวนขั้นต่ำของเด็กใน ‘ว่าง’
; สถานะ (กำลังรอการประมวลผล) ถ้าเป็นเบอร์
; ของกระบวนการ “ว่าง” น้อยกว่านี้
; หมายเลขจากนั้นเด็กบางคนจะถูกสร้างขึ้น.
; pm.max_spare_servers – จำนวนเด็กสูงสุดใน ‘ว่าง’
; สถานะ (กำลังรอการประมวลผล) ถ้าเป็นเบอร์
; ของกระบวนการ “ว่าง” มากกว่านี้
; จำนวนเด็กบางคนจะถูกฆ่า.
; ondemand – ไม่มีลูกถูกสร้างเมื่อเริ่มต้น เด็กจะถูกง่ามเมื่อ
; คำขอใหม่จะเชื่อมต่อ ใช้พารามิเตอร์ต่อไปนี้:
; pm.max_children – จำนวนเด็กสูงสุดที่
; สามารถมีชีวิตอยู่ในเวลาเดียวกัน.
; pm.process_idle_timeout – จำนวนวินาทีหลังจากนั้น
; กระบวนการว่างจะถูกฆ่า.
; หมายเหตุ: ค่านี้มีผลบังคับใช้.

ดังนั้นเราจะเห็นว่ามีค่าที่เป็นไปได้สามค่า:

  • คงที่: กระบวนการ PHP จำนวนคงที่จะได้รับการดูแลรักษาไม่ว่าจะเกิดอะไรขึ้น.
  • พลวัต: เราจะระบุขั้นต่ำและจำนวนสูงสุดของกระบวนการที่ php-fpm จะคงอยู่ตลอดเวลา ณ จุดใดก็ตาม.
  • ตามความต้องการ: กระบวนการสร้างและทำลายได้ดีตามความต้องการ.

ดังนั้นการตั้งค่าเหล่านี้มีความสำคัญอย่างไร?

กล่าวง่ายๆถ้าคุณมีเว็บไซต์ที่มีปริมาณการใช้งานต่ำการตั้งค่า “แบบไดนามิก” จะเป็นการสิ้นเปลืองทรัพยากรเป็นส่วนใหญ่ สมมติว่าคุณมี pm.min_spare_servers ตั้งค่าเป็น 3 กระบวนการ PHP ทั้งสามจะถูกสร้างและดูแลแม้ว่าจะไม่มีการรับส่งข้อมูลบนเว็บไซต์ ในกรณีเช่นนี้“ ondemand” เป็นตัวเลือกที่ดีกว่าปล่อยให้ระบบตัดสินใจเมื่อจะเริ่มกระบวนการใหม่.

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

การใช้ pm = สแตติกแก้ไขจำนวนของกระบวนการลูกปล่อยให้ทรัพยากรระบบสูงสุดที่จะใช้ในการให้บริการการร้องขอมากกว่าการจัดการ PHP หากคุณไปเส้นทางนี้ระวังว่ามันมีแนวทางและข้อผิดพลาด บทความค่อนข้างหนาแน่น แต่มีประโยชน์อย่างมากเกี่ยวกับเรื่องนี้ ที่นี่.

คำพูดสุดท้าย

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

แม้ว่าคุณจะรู้การตั้งค่า php-fpm ทั้งหมดด้วยใจความสำเร็จก็ไม่ได้รับประกัน หากคุณไม่มีเงื่อนงำเกี่ยวกับการมีอยู่ของ php-fpm คุณไม่จำเป็นต้องเสียเวลากังวลกับมัน แค่ทำในสิ่งที่คุณทำอยู่แล้วและทำต่อไป.

ในเวลาเดียวกันให้หลีกเลี่ยงการสิ้นสุดของการเป็นขี้ยาประสิทธิภาพ ใช่คุณสามารถรับประสิทธิภาพที่ดียิ่งขึ้นด้วยการคอมไพล์ PHP ใหม่ตั้งแต่เริ่มต้นและลบโมดูลทั้งหมดที่คุณจะไม่ใช้ แต่วิธีนี้ไม่เพียงพอในสภาพแวดล้อมการผลิต แนวคิดทั้งหมดของการเพิ่มประสิทธิภาพบางอย่างคือดูว่าความต้องการของคุณแตกต่างจากค่าเริ่มต้น (ซึ่งพวกเขาไม่ค่อยทำ!) และทำการเปลี่ยนแปลงเล็กน้อยตามที่ต้องการ.

หากคุณไม่พร้อมที่จะใช้เวลาในการปรับแต่งเซิร์ฟเวอร์ PHP ของคุณคุณอาจพิจารณาใช้ประโยชน์จากแพลตฟอร์มที่น่าเชื่อถือเช่น Kinsta ผู้ดูแลการเพิ่มประสิทธิภาพและความปลอดภัย.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map