ดูกองเซิร์ฟเวอร์ WordPress สมัยใหม่

คุณจำได้ไหมว่าเมื่อใดที่คุณสามารถเรียกใช้เว็บไซต์ WordPress ที่ "เร็ว" ด้วยเซิร์ฟเวอร์ Apache และ PHP ได้? ใช่นั่นคือวัน! สิ่งต่าง ๆ นั้นซับซ้อนน้อยกว่ามากในตอนนั้น

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

• สิทธิ์และการเป็นเจ้าของระบบไฟล์ WordPress ที่เหมาะสม
• การย้ายเว็บไซต์ WordPress โดยไม่ยุ่งยาก
• วิธีพัฒนา WordPress ในเครื่องด้วย MAMP
• วิธีการแคชแบบ Do-It-Yourself ด้วย WordPress

ดังนั้น กองเซิร์ฟเวอร์ WordPress จึงต้องมีการพัฒนาตลอดหลายปีที่ผ่านมา เพื่อให้ทันกับความต้องการความเร็วนี้ ส่วนหนึ่งของวิวัฒนาการนี้ ต้องเพิ่มเกียร์สองสามเกียร์ในเครื่องยนต์ เกียร์รุ่นเก่าบางตัวก็ต้องเปลี่ยนเช่นกัน

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

ภาพรวม

ก่อนดำน้ำให้ซูมออกดูภาพใหญ่กันก่อนครับ สแต็คเซิร์ฟเวอร์ WordPress ใหม่นี้มีลักษณะอย่างไร นี่คือคำตอบ:

ไดอะแกรมด้านบนให้ภาพรวมที่ดีว่าสแต็คเซิร์ฟเวอร์ WordPress สมัยใหม่มีหน้าตาเป็นอย่างไร ในระดับสูง เราสามารถแบ่งสิ่งที่เกิดขึ้นออกเป็นสามส่วน:

• วัฏจักรการตอบกลับคำขอระหว่างเบราว์เซอร์และ WordPress
• WordPress (ซึ่งเป็นสคริปต์ที่รันไทม์ของ PHP);
• วงจรผลลัพธ์การสืบค้นระหว่าง WordPress และฐานข้อมูล MySQL

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

ในกรณีส่วนใหญ่ การเพิ่มประสิทธิภาพเหล่านี้เกี่ยวข้องกับการติดตั้งบริการใหม่บนเซิร์ฟเวอร์ของคุณ บางครั้ง บริการเหล่านี้ต้องการความช่วยเหลือจากปลั๊กอินเพื่อโต้ตอบกับ WordPress จะมีบางครั้งที่คุณสามารถหลีกเลี่ยงได้ด้วยการติดตั้งปลั๊กอิน คุณจะเห็นตัวเลือกต่างๆ มากมายในบทความนี้

วัฏจักรการตอบกลับคำขอ

ทุกอย่างเริ่มต้นด้วยเบราว์เซอร์ สมมติว่าคุณต้องการดูโฮมเพจของ modern.wordpress-stack.org เบราว์เซอร์ของคุณจะเริ่มต้นด้วยการส่งคำขอ HTTP ไปยังเว็บเซิร์ฟเวอร์ที่โฮสต์ไว้ อีกด้านหนึ่ง เว็บเซิร์ฟเวอร์จะรับคำขอของคุณและเปลี่ยนเป็นการตอบกลับ HTTP

คำตอบแรกนี้ควรเป็นเนื้อหา HTML ของหน้าแรกของ modern.wordpress-stack.org (เว้นแต่จะมีข้อผิดพลาด) อย่างไรก็ตาม งานของเบราว์เซอร์ของคุณยังไม่เสร็จสิ้น ไม่ หน้าแรกนั้นยังคงต้องการไฟล์มากกว่านี้ ไฟล์ที่พบบ่อยที่สุดคือ CSS, JavaScript และไฟล์รูปภาพ

ดังนั้น เบราว์เซอร์จะส่งคำขอสำหรับไฟล์เหล่านั้น เว็บเซิร์ฟเวอร์จะตอบกลับด้วยไฟล์ที่ร้องขอ (อีกครั้ง ตราบใดที่ไม่มีข้อผิดพลาด) รอบนี้จะดำเนินต่อไปจนกว่าเบราว์เซอร์จะมีข้อมูลเพียงพอที่จะแสดงหน้าแรก ยิ่งวงจรนี้เกิดขึ้นเร็วเท่าไหร่ เว็บไซต์ก็จะยิ่งโหลดเร็วขึ้นเท่านั้น

นี่คือการทำให้เข้าใจง่ายขึ้นอย่างเห็นได้ชัด แต่สิ่งนี้คือวิธีการทำงานของเว็บไซต์ WordPress ส่วนใหญ่

การเพิ่มประสิทธิภาพรอบการตอบกลับคำขอ

เอาล่ะ นี่นำเราไปสู่คำถามที่ชัดเจนว่า เราจะทำให้เว็บเซิร์ฟเวอร์ทำงานรอบนี้เร็วขึ้นได้อย่างไร นี่เป็นคำถามที่ดีและเป็นส่วนหนึ่งของเหตุผลว่าทำไม WordPress เซิร์ฟเวอร์สแต็คที่ทันสมัยจึงมีอยู่

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

บริการอื่นๆ เหล่านี้มักเป็นคอขวดของวงจรการตอบกลับคำขอนี้ สำหรับ WordPress ปัญหาคอขวดนี้คือ PHP ซึ่งเป็นสาเหตุที่ทำให้วงจรการตอบสนองต่อคำขอเหมาะสมที่สุดมีสองสิ่ง เราต้องการให้เว็บเซิร์ฟเวอร์:

• รับคำขอให้น้อยที่สุด
• ส่งต่อคำขอไปยัง PHP ให้น้อยที่สุด

กองเซิร์ฟเวอร์ WordPress ที่ทันสมัยมุ่งเน้นไปที่อันสุดท้ายนี้ ต้องการส่งต่อคำขอไปยัง PHP ให้น้อยที่สุด นั่นจะเป็นเป้าหมายหลักในการเพิ่มประสิทธิภาพกอง

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

สแต็กองค์ประกอบสำหรับรอบการตอบกลับคำขอ

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

เว็บเซิร์ฟเวอร์

เราได้พูดถึงเว็บเซิร์ฟเวอร์มาบ้างแล้ว มีผู้เล่นรายใหญ่สามคนในพื้นที่เว็บเซิร์ฟเวอร์:

• Apache
• บริการข้อมูลทางอินเทอร์เน็ต (IIS)
• nginx

เมื่อรวมกันแล้วสิ่งเหล่านี้คิดเป็นมากกว่า 90% ของส่วนแบ่งการตลาดของเว็บเซิร์ฟเวอร์บนอินเทอร์เน็ต เราจะมุ่งเน้นไปที่ Apache และ nginx แม้ว่า IIS จะสามารถใช้เพื่อรัน WordPress ได้ แต่ก็ไม่ใช่เรื่องปกติเพราะใช้งานได้กับ Windows เท่านั้น และเซิร์ฟเวอร์ WordPress ส่วนใหญ่ใช้ Linux

สิ่งนี้ทำให้เรามี Apache และ nginx ตลอดชีวิตของ WordPress Apache เป็นเว็บเซิร์ฟเวอร์ที่แนะนำ เรามี LAMP stack (Linux, Apache, MySQL และ PHP) ซึ่งรัน WordPress ได้ทั้งบนคอมพิวเตอร์และเซิร์ฟเวอร์

แต่เบื้องหลังสิ่งต่าง ๆ กำลังเปลี่ยนไป มีผู้เล่นใหม่เข้ามาในเมือง และชื่อของมันคือ nginx Automattic และ WordPress.com ใช้งานมาตั้งแต่ปี 2008 เป็นเว็บเซิร์ฟเวอร์ที่มีเปอร์เซ็นต์สูงสุดของเว็บไซต์ที่มีการเข้าชมสูง (ส่วนใหญ่ใช้ WordPress) นั่นเป็นสาเหตุที่บริษัทโฮสติ้งระดับไฮเอนด์และเอเจนซี่ WordPress ชั้นนำจำนวนมากใช้เป็นเว็บเซิร์ฟเวอร์ของพวกเขา

ไม่ใช่ว่า Apache เป็นเว็บเซิร์ฟเวอร์ที่ไม่ดี มีผู้เชี่ยวชาญ Apache ที่สามารถทำให้มันทำงานได้ดีภายใต้ปริมาณการใช้งานจำนวนมาก มันไม่ได้ทำออกมาได้ดีเช่นกันเมื่อแกะกล่องหรือกับการกำหนดค่า WordPress มาตรฐาน

ในขณะเดียวกัน จุดประสงค์เดียวของ nginx คือเพื่อรองรับการรับส่งข้อมูลจำนวนมาก นั่นเป็นเหตุผลที่ Igor Sysoev เริ่มโครงการเมื่อเขาทำงานที่ Rambler

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

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

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

HTTP/2 เป็นอีกหนึ่งคุณลักษณะของเว็บเซิร์ฟเวอร์ที่สำคัญที่คุณควรรู้ เป็นเวอร์ชันถัดไปของ HTTP ซึ่งเป็นโปรโตคอลที่ขับเคลื่อนวงจรการตอบกลับคำขอทั้งหมดของเรา

ก่อนการมาถึงของ HTTP/2 เบราว์เซอร์สามารถมีการเชื่อมต่อไปยังเว็บเซิร์ฟเวอร์ได้เพียงหกครั้ง และการเชื่อมต่อแต่ละครั้งสามารถจัดการคำขอได้ครั้งละหนึ่งคำขอเท่านั้น ดังนั้น ในทางปฏิบัติ รอบการตอบกลับคำขอจึงถูกจำกัดไว้ที่คำขอหกรายการต่อรอบ

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

วิธีแก้ไขปัญหาเฉพาะหน้าที่รู้จักกันดีวิธีหนึ่งคือการรวมไฟล์ CSS และ JavaScript ในสถานการณ์ที่เหมาะสม การทำเช่นนี้จะทำให้จำนวนคำขอทั้งหมดสำหรับไฟล์ CSS และ JavaScript ลดลงเหลือสองไฟล์: คำขอหนึ่งสำหรับ JavaScript และอีกหนึ่งคำขอสำหรับ CSS

สิ่งนี้ไม่จำเป็นสำหรับ HTTP/2 HTTP/2 อนุญาตให้มีการร้องขอไม่จำกัดจำนวนต่อการเชื่อมต่อ ซึ่งจะทำให้คำขอพิเศษทั้งหมดหลังจากการตอบกลับ HTML เริ่มต้นเกิดขึ้นพร้อมกันได้

สิ่งนี้มีผลกระทบต่อประสิทธิภาพอย่างมาก งานจำนวนมากในการปรับให้เหมาะสมสแต็กเซิร์ฟเวอร์เป็นศูนย์กลางในวงจรการตอบกลับคำขอ ด้วยการลดจำนวนรอบให้เหลือเพียงไม่กี่ครั้ง HTTP/2 ได้ทำงานให้เราอย่างมากมาย

แคช HTTP

ส่วนที่สำคัญที่สุดของสแต็คเซิร์ฟเวอร์ WordPress ที่ทันสมัยคือแคช HTTP ในโลกของ WordPress เรายังเรียกหน้านี้ว่าแคช วัตถุประสงค์ของแคช HTTP คือเพื่อแคชการตอบสนองต่อคำขอ สิ่งนี้หมายความว่า?

กลับมาที่ตัวอย่างก่อนหน้านี้ของเรา เบราว์เซอร์ส่งคำขอสำหรับหน้าแรกของ modern.wordpress-stack.org และเว็บเซิร์ฟเวอร์ได้รับคำขอนั้นและส่งต่อไปยัง PHP

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

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

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

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

วิธีนี้ช่วยลดรอบเวลาการตอบกลับคำขอได้อย่างมาก ทำให้เว็บไซต์โหลดเร็วขึ้น นอกจากนี้ยังช่วยให้เว็บเซิร์ฟเวอร์จัดการคำขอพร้อมกันได้มากขึ้นโดยไม่ทำให้เสียหาย

รสชาติที่แตกต่างของ HTTP Cache

ณ จุดนี้ คุณควรสงสัยว่า “ฉันจะเอาเด็กคนนี้ไปอยู่บนเซิร์ฟเวอร์ของฉันโดยเร็วได้อย่างไร!” ข่าวดีก็คือการติดตั้งแคช HTTP บนเซิร์ฟเวอร์ WordPress นั้นค่อนข้างง่าย เป็นส่วนประกอบที่มีตัวเลือกที่หลากหลายที่สุด

ติดตั้งปลั๊กอินแคชหน้า

วิธีที่ง่ายที่สุดคือการติดตั้งปลั๊กอินแคชหน้า คุณมีตัวเลือกสองสามอย่างให้เลือกจาก:

• แบตแคช
• ไฮเปอร์แคช
• ตัวเปิดใช้งานแคช
• WP Rocket
• WP Super Cache
• W3 แคชทั้งหมด

ทั้งหมดยกเว้น WP Rocket มีให้ใช้งานเป็นปลั๊กอินฟรีในไดเร็กทอรี WordPress ดังนั้น คุณสามารถติดตั้งและทดสอบได้ทันที ดังที่กล่าวไปแล้วจากปลั๊กอินทั้งสี่ตัว ปลั๊กอินที่ดีที่สุดคือ WP Rocket แม้ว่าจะเป็นปลั๊กอินแบบชำระเงิน แต่ก็ทำมากกว่าแค่สร้างแคช HTTP ประโยชน์อื่นๆ เหล่านี้ช่วยขยายงานที่แคช HTTP กำลังทำอยู่

ปลั๊กอินแคชหน้าทำงานอย่างไร

ปลั๊กอินทั้งหมดเหล่านี้ใช้ประโยชน์จากดรอปอินที่ WordPress เตรียมไว้ให้สำหรับการแคช แคชแบบดรอปอินนี้ช่วยให้ปลั๊กอินสร้างระบบแคช HTTP ภายใน WordPress แคชดรอปอินต้องการสองสิ่งในการทำงาน

ขั้นแรก ไฟล์ดร advanced-cache.php ต้องอยู่ในโฟลเดอร์ wp-content นั่นคือไฟล์จริง แต่แตกต่างจากดรอปอินของ WordPress ส่วนใหญ่ รายการนี้ไม่ได้เปิดใช้งานโดยค่าเริ่มต้น WordPress ยังต้องการค่าคงที่ WP_CACHE ให้เป็น true เพื่อโหลดดรอปอิน ในกรณีส่วนใหญ่ คุณจะตั้งค่านั้นใน wp-config.php

ไดอะแกรมด้านบนแสดงสิ่งที่เกิดขึ้นเมื่อคุณเปิดใช้งานดรอปอินด้วยปลั๊กอินแคช WordPress โหลดดรอปอินใน wp-settings.php ระหว่างกระบวนการโหลด นี่ยังเร็วพอในกระบวนการที่ WordPress ยังไม่ได้ดำเนินการใดๆ ให้เสียเวลา

ปลั๊กอินแคชจะตรวจสอบว่าได้แคชการตอบสนองต่อคำขอแล้วหรือไม่ หากมี จะส่งคืนการตอบกลับที่แคชไว้ หากไม่เป็นเช่นนั้น จะเป็นการเปิดบัฟเฟอร์เอาต์พุต PHP และ WordPress จะดำเนินการโหลดต่อไป

ตอนนี้การบัฟเฟอร์เอาต์พุตเป็นระบบที่น่าสนใจ ทำหน้าที่ดักจับเอาต์พุตทั้งหมดจากสคริปต์ PHP ในตัวแปรสตริง จนกว่าจะมีสิ่งใดสิ่งหนึ่งเกิดขึ้น:

• คุณบอกให้ PHP หยุดบัฟเฟอร์เอาต์พุตโดยใช้หนึ่งในฟังก์ชันในตัว
• สคริปต์ PHP เสร็จสิ้นและจำเป็นต้องส่งคืนการตอบสนองต่อเบราว์เซอร์

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

ให้เว็บเซิร์ฟเวอร์ทำมัน

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

ไดอะแกรมด้านบนให้ภาพรวมของสิ่งที่เกิดขึ้นในเว็บเซิร์ฟเวอร์ เว็บเซิร์ฟเวอร์ได้รับคำขอและตรวจสอบด้วยแคช HTTP หากแคชการตอบสนองแล้ว แคช HTTP จะส่งกลับ

มิฉะนั้น จะส่งต่อคำขอไปยังโมดูล PHP (โดยปกติคือ FastCGI) มันจะส่งคำขอไปยัง WordPress เพื่อให้สามารถสร้างการตอบกลับได้ โมดูลแคช HTTP จะแคชการตอบสนองนั้นระหว่างทางกลับ

ทั้ง Apache และ nginx มาพร้อมกับความสามารถในการเพิ่มระบบแคช HTTP มี nginx หนึ่งติดตั้งอยู่ภายใน Apache หนึ่งเป็นโมดูลแยกต่างหากที่คุณต้องเพิ่มในการติดตั้ง Apache ของคุณ

มีข้อมูลไม่มากนักเกี่ยวกับวิธีใช้โมดูล Apache กับ PHP หรือ WordPress อาจเป็นเพราะไม่ได้รับความนิยมในกลุ่ม Apache หรืออาจเป็นเพราะมีปัญหาบางอย่าง มีปัญหาอย่างน้อยหนึ่งปัญหาที่ยังเปิดอยู่

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

เพิ่มวานิชให้กับ Stack

วานิชคืออะไร? เป็นเซิร์ฟเวอร์แคช HTTP เฉพาะ (หรือตามที่นักพัฒนาต้องการเรียกว่าตัวเร่ง HTTP) เว็บไซต์ที่มีการเข้าชมสูงและบริษัทโฮสติ้งระดับพรีเมียมส่วนใหญ่ใช้เป็นโซลูชันแคช HTTP

พวกเขาใช้มันเพราะมันทรงพลังและให้ความยืดหยุ่นมากที่สุด วานิชมีภาษาการกำหนดค่าของตัวเองที่เรียกว่า VCL ช่วยให้คุณควบคุมทุกองค์ประกอบของกระบวนการแคช วานิชยังมาพร้อมกับเครื่องมือมากมายสำหรับวิเคราะห์ว่าแคชทำอะไรอยู่และทำงานอย่างไร

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

อย่างไรก็ตาม พลังและความยืดหยุ่นนี้มาพร้อมกับราคา วานิชยังเป็นตัวเลือกแคช HTTP ที่ซับซ้อนที่สุดอีกด้วย มันไม่ทำอะไรเลยนอกจากแคชการตอบสนอง HTTP ไม่รองรับการยกเลิก SSL ซึ่งนักพัฒนา WordPress ส่วนใหญ่ต้องการ (หรือควรต้องการ) ซึ่งหมายความว่าสแต็คเซิร์ฟเวอร์ WordPress ที่ทันสมัยของเราจะซับซ้อนมากขึ้นเมื่อเราใช้งาน

แผนภาพด้านบนแสดงให้เห็นถึงความซับซ้อนพิเศษนี้ ตอนนี้เรามีส่วนประกอบเพิ่มเติมสองอย่างในกองเซิร์ฟเวอร์ WordPress ของเรา: วานิชและพร็อกซีย้อนกลับ

พร็อกซีย้อนกลับอยู่ที่นั่นเพื่อเอาชนะข้อ จำกัด ที่วานิชมีกับ SSL มันอยู่หน้าวานิชและถอดรหัสคำขอที่เซิร์ฟเวอร์ของเราได้รับ คุณยังสามารถเรียก reverse proxy ประเภทนี้ว่าพร็อกซีการยุติ SSL จากนั้นพร็อกซีจะส่งคำขอที่ถอดรหัสเหล่านี้ไปยังวานิชเพื่อดำเนินการ

เมื่อคำขอไปถึงวานิช ไฟล์การกำหนดค่า VCL ก็จะเริ่มทำงาน สิ่งเหล่านี้คือสมองของวานิช ตัวอย่างเช่น พวกเขาบอกวิธี:

• วิเคราะห์ ทำความสะอาด และแก้ไขคำขอที่เข้ามา
• ค้นหาการตอบสนองที่แคชไว้
• วิเคราะห์ ทำความสะอาด และแก้ไขการตอบกลับจาก WordPress
• แคชการตอบกลับเหล่านี้กลับ;
• จัดการคำขอเพื่อลบการตอบสนองอย่างน้อยหนึ่งรายการออกจากแคช

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

WordPress

เอาล่ะ คำขอของเราสำหรับหน้าแรกของ modern.wordpress-stack.org ได้โจมตี WordPress แล้ว ผ่านวงจรการตอบกลับคำขอที่เราเพิ่งกล่าวถึง แคช HTTP ทำทุกอย่างที่ทำได้เพื่อค้นหาการตอบสนอง HTTP เพื่อส่งกลับ

แต่ไม่มีการตอบสนอง HTTP ที่แคชไว้เพื่อส่งกลับไปยังเบราว์เซอร์ ณ จุดนั้น แคช HTTP ไม่มีทางเลือกอื่น ต้องส่งต่อคำขอ HTTP ไปยัง WordPress

ทุกอย่างอยู่ในมือของ WordPress แล้ว WordPress ต้องเปลี่ยนคำขอ HTTP ของเราเป็นการตอบกลับ HTTP และส่งกลับไปยังแคช HTTP ดังที่เราเห็นก่อนหน้านี้ นี่คือคอขวดหลักของสแต็คเซิร์ฟเวอร์ WordPress ที่ทันสมัยทั้งหมดของเรา

สาเหตุของคอขวดนี้เป็นสองเท่า WordPress มีโค้ด PHP มากมายให้ดำเนินการ การดำเนินการนี้ใช้เวลานาน และ PHP ทำงานช้ากว่านั้นก็จะใช้เวลานานขึ้น

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

การเพิ่มประสิทธิภาพรันไทม์ PHP

กลับไปที่ PHP กัน ในขณะนี้ WordPress มีข้อกำหนดขั้นต่ำ PHP 5.2 PHP เวอร์ชันนี้มีอายุเกือบ 10 ปีแล้ว! (ทีมงาน PHP หยุดสนับสนุนในปี 2554)

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

ใช้ PHP เวอร์ชันล่าสุด

สิ่งที่ง่ายที่สุดที่คุณสามารถทำได้คืออัปเกรดเวอร์ชัน PHP ของคุณ เวอร์ชัน 5.4, 5.5 และ 5.6 ทั้งหมดเห็นการปรับปรุงประสิทธิภาพ การปรับปรุงที่ใหญ่ที่สุดคือจาก 5.3 เป็น 5.4 การเปลี่ยนไปใช้ WordPress เพิ่มประสิทธิภาพได้พอสมควร

ติดตั้ง Opcode Caching

การแคช Opcode เป็นอีกวิธีหนึ่งในการเพิ่มความเร็ว PHP ในฐานะที่เป็นภาษาสคริปต์ฝั่งเซิร์ฟเวอร์ PHP มีข้อบกพร่องใหญ่: จำเป็นต้องรวบรวมสคริปต์ PHP ทุกครั้งที่ดำเนินการ

วิธีแก้ปัญหานี้คือแคชโค้ด PHP ที่คอมไพล์แล้ว ด้วยวิธีนี้ PHP ไม่จำเป็นต้องคอมไพล์ทุกครั้งที่รัน นี่คืองานของแคช opcode

ก่อน PHP 5.5 นั้น PHP ไม่ได้มาพร้อมกับ opcode cache คุณต้องติดตั้งด้วยตนเองบนเซิร์ฟเวอร์ นี่เป็นอีกเหตุผลหนึ่งที่ว่าทำไมการใช้ PHP เวอร์ชันล่าสุดจึงดีกว่า

เปลี่ยนไปใช้คอมไพเลอร์รุ่นต่อไป

สิ่งสุดท้ายที่คุณสามารถทำได้คือเปลี่ยนไปใช้หนึ่งในสองคอมไพเลอร์รุ่นใหม่ ได้แก่ HHVM ของ Facebook หรือ PHP 7 ซึ่งเป็น PHP เวอร์ชันล่าสุด (ทำไมต้อง PHP 7 เป็นเรื่องยาว)

Facebook และทีมงาน PHP ได้สร้างคอมไพเลอร์สองตัวนี้ขึ้นมาจากพื้นฐาน พวกเขาต้องการใช้ประโยชน์จากกลยุทธ์การรวบรวมที่ทันสมัยมากขึ้น HHVM ใช้การคอมไพล์แบบทันเวลา ในขณะที่ PHP 7 ใช้การคอมไพล์ล่วงหน้า ทั้งสองมีการปรับปรุงประสิทธิภาพที่เหลือเชื่อเหนือ PHP 5 ที่ดี

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

อย่างไรก็ตาม ควรเน้นว่า HHVM ไม่ใช่คอมไพเลอร์ PHP อย่างเป็นทางการ ไม่สามารถใช้งานร่วมกับ PHP ได้ 100% เหตุผลก็คือ HHVM ไม่ได้ออกแบบมาเพื่อรองรับ PHP เท่านั้น; นอกจากนี้ยังเป็นคอมไพเลอร์สำหรับภาษาโปรแกรมแฮ็คของ Facebook

PHP 7 เป็นคอมไพเลอร์ PHP อย่างเป็นทางการ ไม่ได้มีมานานแล้ว ทีมงาน PHP ได้เปิดตัวในเดือนธันวาคม 2015 ซึ่งไม่ได้ทำให้บางบริษัทโฮสติ้ง WordPress ไม่สามารถสนับสนุนได้

ข่าวดีก็คือ WordPress เองนั้นเข้ากันได้กับคอมไพเลอร์ทั้งสอง 100%! ข่าวร้ายก็คือไม่ใช่ว่าปลั๊กอินและธีมทั้งหมดเป็นเพราะเวอร์ชัน PHP ขั้นต่ำสำหรับ WordPress ยังคงเป็น 5.2

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

วงจรผลการสืบค้น

ณ จุดนี้รันไทม์ของ PHP กำลังดำเนินการผ่านไฟล์ WordPress PHP ทั้งหมดและดำเนินการ อย่างไรก็ตาม ไฟล์ WordPress PHP เหล่านี้ไม่มีข้อมูลใดๆ พวกเขามีเฉพาะรหัส WordPress

ปัญหาคือ WordPress เก็บข้อมูลทั้งหมดไว้ในฐานข้อมูล MySQL รันไทม์ของ PHP จำเป็นต้องสืบค้นฐานข้อมูลนั้นเพื่อเข้าถึง เซิร์ฟเวอร์ MySQL ส่งคืนผลลัพธ์ของแบบสอบถามนั้น และรันไทม์ของ PHP ยังคงรันไฟล์ WordPress PHP ต่อไป… นั่นคือ จนกว่าจะต้องการข้อมูลอีกครั้ง

การกลับไปกลับมานี้สามารถเกิดขึ้นได้ตั้งแต่สองสามครั้งจนถึงสองสามร้อยครั้ง (คุณอาจต้องการพูดคุยกับนักพัฒนาของคุณหากเป็นอย่างหลัง!) นั่นเป็นสาเหตุที่ทำให้เกิดปัญหาคอขวดครั้งใหญ่

การเพิ่มประสิทธิภาพวงจรผลการสืบค้น

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

วิธีที่ชัดเจนในการแก้ไขปัญหานี้คือการลดจำนวนการสืบค้นที่ WordPress ต้องทำ และนั่นก็คุ้มค่าเสมอ! แต่ไม่ใช่สิ่งที่กองเซิร์ฟเวอร์ WordPress สมัยใหม่สามารถช่วยได้

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

ทั้งสองตัวเลือกนี้มีไว้เพื่อทำสิ่งเดียวกัน: ทำให้ PHP รอผลลัพธ์จากฐานข้อมูลให้น้อยที่สุด ซึ่งจะทำให้ WordPress เร็วขึ้น

กององค์ประกอบสำหรับรอบผลการสืบค้น

มาดูองค์ประกอบสแต็กต่างๆ ที่เกี่ยวข้องกับวงจรผลลัพธ์การสืบค้นกัน ส่วนนี้ของสแต็กไม่ซับซ้อน แต่ยังคงเกี่ยวข้องกับองค์ประกอบมากกว่าหนึ่งอย่าง กล่าวคือ เซิร์ฟเวอร์ฐานข้อมูล MySQL และออบเจกต์แคช

เซิร์ฟเวอร์ฐานข้อมูล MySQL

ไม่กี่ปีที่ผ่านมาเซิร์ฟเวอร์ฐานข้อมูล MySQL จะมีความหมายเหมือนกันสำหรับทุกคน เป็นเซิร์ฟเวอร์ที่ติดตั้งเซิร์ฟเวอร์ MySQL แต่สิ่งต่างๆ ได้เปลี่ยนไปอย่างมากในช่วงไม่กี่ปีที่ผ่านมา

กลุ่มต่างๆ ไม่พอใจกับวิธีที่ Oracle จัดการโปรเจ็กต์ MySQL ดังนั้นแต่ละกลุ่มจึงแยกส่วนและสร้างเวอร์ชันของตนเองขึ้นมาซึ่งคุณสามารถ "เข้าร่วม" แทนได้ ผลที่ได้คือขณะนี้มีเซิร์ฟเวอร์ฐานข้อมูล MySQL หลายตัว

เซิร์ฟเวอร์ MySQL "อย่างเป็นทางการ" ใหม่คือเซิร์ฟเวอร์ MariaDB เป็นเซิร์ฟเวอร์ MySQL เวอร์ชันที่พัฒนาโดยชุมชน ชุมชนมีแผนที่จะรักษาความเข้ากันได้อย่างสมบูรณ์กับโปรเจ็กต์เซิร์ฟเวอร์ MySQL

อีกทางเลือกหนึ่งที่ได้รับความนิยมสำหรับ MySQL คือเซิร์ฟเวอร์ Percona Percona แตกต่างจาก MariaDB เป็นสาขาของ MySQL มากกว่า นักพัฒนาซอฟต์แวร์ไม่ได้ต่อต้านโครงการ MySQL เลย พวกเขาแค่ต้องการมุ่งเน้นไปที่การปรับปรุงประสิทธิภาพของ MySQL ในเวลาต่อมา ทีม MariaDB ได้รวมการปรับปรุงประสิทธิภาพบางส่วนเข้ากับโครงการ MariaDB

ในตอนท้ายของวัน คุณสามารถเลือกรายการที่คุณต้องการได้ ประสิทธิภาพไม่แตกต่างกันระหว่างเซิร์ฟเวอร์ Percona และเซิร์ฟเวอร์ MariaDB (สำหรับพวกเราส่วนใหญ่) พวกเขาทั้งสองทำงานได้ดีกว่า MySQL อย่างไรก็ตาม Percona ยังคงรักษาความเข้ากันได้อย่างใกล้ชิดกับโปรเจ็กต์ Oracle

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

เซิร์ฟเวอร์ฐานข้อมูลมีเอ็นจิ้นการจัดเก็บข้อมูลหลายตัว เราจะไม่ดูทั้งหมด เราสนใจแค่สองคนเท่านั้น: InnoDB และ MyISAM

ตามค่าเริ่มต้น WordPress ใช้เครื่องมือฐานข้อมูล MySQL เริ่มต้น ก่อน MySQL 5.5 เอ็นจิ้นนั้นคือ MyISAM หากคุณใช้งานเว็บไซต์ WordPress ขนาดเล็ก MyISAM ก็ใช้ได้ MyISAM ประสบปัญหาด้านประสิทธิภาพเมื่อเว็บไซต์มีขนาดใหญ่ขึ้น ณ จุดนั้น InnoDB เป็นตัวเลือกเดียวสำหรับเอ็นจิ้นฐานข้อมูล

ปัญหาเดียวของ InnoDB คือต้องมีการปรับแต่งเพื่อให้ทำงานได้ดีที่สุด หากคุณกำลังใช้งานเซิร์ฟเวอร์ฐานข้อมูลขนาดใหญ่ คุณอาจต้องปรับเปลี่ยนสิ่งต่างๆ โชคดีสำหรับเราที่มีเครื่องมือที่ช่วยในเรื่องนั้น

MySQLTuner เป็นสคริปต์ขนาดเล็กที่วิเคราะห์เซิร์ฟเวอร์ฐานข้อมูลของคุณ จะสร้างรายงานและให้คำแนะนำในการปรับแต่ง

แคชวัตถุ

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

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

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

แม้ว่า WordPress จะพยายามอย่างดีที่สุดเพื่อใช้ประโยชน์จากแคชอ็อบเจ็กต์ แต่ปลั๊กอินหรือธีมก็ไม่จำเป็น หากปลั๊กอินหรือธีมสร้างการสืบค้นฐานข้อมูลจำนวนมากและไม่แคชผลลัพธ์ สแต็กไม่สามารถทำอะไรกับมันได้

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

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

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

แคชอ็อบเจ็กต์ถาวรมักมาในรูปแบบของปลั๊กอิน ปลั๊กอินนั้นจะใช้ประโยชน์จากดร object-cache.php เพื่อทำงาน ดรอปอินนี้ช่วยให้ผู้เขียนปลั๊กอินเปลี่ยนพฤติกรรมเริ่มต้นของแคชอ็อบเจ็กต์

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

ปลั๊กอินแคชวัตถุถาวร

ปัจจุบันนี้ มีสองตัวเลือกที่เก็บข้อมูลยอดนิยมสำหรับการแคชอ็อบเจ็กต์ถาวร:

• Memcached (ปลั๊กอิน)
• Redis (ปลั๊กอิน)

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

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

คุณควรติดตั้งตัวใด ในทางปฏิบัติ ไม่มีความแตกต่างระหว่างสองสิ่งนี้สำหรับการแคชอ็อบเจ็กต์มากนัก ในอดีต ตัวเลือกยอดนิยมคือ Memcached สิ่งนี้มีการเปลี่ยนแปลงในช่วงไม่กี่ปีที่ผ่านมา Redis ได้เพิ่มคุณสมบัติมากมายที่ทำให้เป็นตัวเลือกสำหรับการแคชวัตถุ

รับเซิร์ฟเวอร์ WordPress ที่ทันสมัยของคุณเอง

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

แต่ถ้าคุณต้องการโดยไม่ทำลายธนาคารล่ะ มีเครื่องมือสองสามอย่างสำหรับทุกคนที่ต้องการทำเองและจ่ายน้อยกว่าสำหรับการโฮสต์ ลองดูที่พวกเขา

DebOps สำหรับ WordPress

DebOps สำหรับ WordPress เป็นเครื่องมือที่ฉันสร้างขึ้นเพื่อช่วยทุกคนในการสร้างเซิร์ฟเวอร์ WordPress ที่ทันสมัย ภารกิจของมันคือการทำให้เซิร์ฟเวอร์ WordPress ทันสมัยพร้อมสำหรับทุกคนในชุมชน นั่นเป็นเหตุผลที่ฉันพยายามทำให้ใช้งานง่ายที่สุด คุณไม่จำเป็นต้องมีความรู้ด้านการดูแลระบบเพื่อใช้งาน

DebOps สำหรับ WordPress กำหนดค่าเซิร์ฟเวอร์ดังต่อไปนี้:

• HHVM (จนกระทั่ง PHP 7 กลายเป็นที่เก็บ Linux อย่างเป็นทางการ)
• MariaDB
• nginx
• Redis
• วานิช

เครื่องมือนี้ทำมากกว่าแค่กำหนดค่าเซิร์ฟเวอร์ด้วยเทคโนโลยีล่าสุด นอกจากนี้ยังดูแลการรักษาความปลอดภัยเซิร์ฟเวอร์ให้กับคุณ นี่คือสิ่งที่ผู้คนมักมองข้ามเมื่อจัดการเซิร์ฟเวอร์ของตนเอง

EasyEngine

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

ตัวอย่างเช่น ช่วยให้คุณตั้งค่าเซิร์ฟเวอร์ด้วย HHVM หรือ PHP 7 ซึ่งช่วยให้คุณเลือกระหว่าง Memcached และ Redis สำหรับการจัดเก็บข้อมูลถาวรของคุณ และช่วยให้คุณติดตั้งเครื่องมือผู้ดูแลระบบ เช่น phpMyAdmin

นอกจากนี้ยังมีตัวเลือกมากมายในการสร้างเว็บไซต์ WordPress คุณสามารถบอกให้ตั้งค่าเว็บไซต์ด้วยแคช HTTP โดยใช้ปลั๊กอินหรือ nginx ความยืดหยุ่นทั้งหมดนี้ทำให้ EasyEngine เป็นเครื่องมือยอดนิยม

Trellis

Trellis เป็นเครื่องมือที่พัฒนาโดย Roots เช่นเดียวกับ DebOps มันกำหนดค่าเซิร์ฟเวอร์ด้วยชุดเทคโนโลยีเซิร์ฟเวอร์เฉพาะ:

• MariaDB
• Memcached
• nginx
• แคช nginx HTTP (ไม่บังคับ)
• PHP7

สิ่งหนึ่งที่ต้องรู้เกี่ยวกับ Trellis คือความสัมพันธ์กับ Bedrock ซึ่งเป็นเครื่องมืออีกอย่างหนึ่งที่สร้างโดย Roots Bedrock เป็นต้นแบบสำหรับการจัดโครงสร้างเว็บไซต์ WordPress โดยใช้หลักการ "Twelve-Factor App"

ทีม Roots ได้สร้าง Trellis เพื่อให้ผู้คนสามารถกำหนดค่าเซิร์ฟเวอร์ที่ใช้เว็บไซต์ WordPress ที่มีโครงสร้างแบบ Bedrock คุณไม่สามารถใช้กับการติดตั้ง WordPress แบบปกติได้ ดังนั้นโปรดจำไว้เสมอว่า

ยุคสมัยเปลี่ยนไป

อย่างที่คุณเห็น เซิร์ฟเวอร์ WordPress มีส่วนเคลื่อนไหวอีกมากมายในปัจจุบัน! แต่สิ่งนี้ไม่จำเป็นต้องเป็นสาเหตุของความสิ้นหวัง มันไม่ได้แย่อย่างที่เห็นเพราะคุณไม่จำเป็นต้องใช้ชิ้นส่วนทั้งหมดเสมอไป

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