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

คุณอาจสนใจ:

วิธีสร้าง Favicon สำหรับเว็บไซต์

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

ปุ่มที่สวยงามสำหรับเว็บไซต์

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

ตัวอย่างหน้า 404

สวัสดีผู้อ่านบล็อกของฉันที่รัก บทความนี้ไม่มีเนื้อหาเกี่ยวกับอะไรเลย ในที่สุดฉันก็มาถึงหน้า 404 แล้ว

แท็กชื่อและคำอธิบายถูกเขียนอย่างไรและที่ไหน

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

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

ขณะทดสอบความเร็วของไซต์ WordPress ของคุณโดยใช้เครื่องมือทดสอบความเร็วออนไลน์ คุณอาจสังเกตเห็นว่าไฟล์ดังกล่าว admin-ajax.phpรับผิดชอบต่อประสบการณ์การโหลดช้า ในบทความนี้ เราจะอธิบายเกี่ยวกับไฟล์นี้และวิธีที่คุณสามารถลดเวลาตอบสนองของเซิร์ฟเวอร์และการใช้งาน CPU โดยการลดจำนวนคำขอที่สร้างโดย admin-ajax.php

admin-ajax.php ใน WordPress คืออะไร?

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

คุณสมบัติที่โดดเด่นสองประการของ Heartbeat API:

1. บันทึกอัตโนมัติ

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

2. บล็อกข้อความ

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

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

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

ตัวอย่างการใช้ชีวิต

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

ตามตั๋วที่กล่าวถึงข้างต้น admin-ajax.php ใน WordPress จะสร้างคำขอทุกๆ 15 วินาที คำขอสามารถเชื่อมต่อกับเซิร์ฟเวอร์ได้

เร่งความเร็วแผงผู้ดูแลระบบ WordPress

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

ติดตั้งปลั๊กอินควบคุม Heartbeat

เข้าสู่ระบบผู้ดูแลระบบ WordPress ของคุณแล้วไปที่ ปลั๊กอิน >> เพิ่มใหม่, หา การควบคุมการเต้นของหัวใจ, ติดตั้งและ เปิดใช้งานของเขา.

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

คุณสามารถเลือกพื้นที่ที่ Heartbeat API จะทำงาน มีสามตัวเลือกให้เลือก:

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

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

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

การสร้างกฎหลายข้อ

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

ตอนนี้คุณได้ตั้งค่าทุกอย่างเรียบร้อยแล้ว ก็ถึงเวลาตรวจสอบว่าปลั๊กอินตัวใดที่ทำให้เว็บไซต์ของคุณช้าลงโดยใช้ไฟล์ admin-ajax.php

ไปที่ GTmetrix ป้อน URL เว็บไซต์ของคุณ การวิเคราะห์ไซต์จะใช้เวลาสักครู่ หลังจากนั้นไปที่แท็บ Waterfall แล้วคุณจะเห็นว่าไฟล์ใช้เวลาในการเชื่อมต่อและตอบสนองนานเท่าใด เลื่อนลงไปเล็กน้อยเพื่อดูว่ามีรายการหรือไม่ โพสต์ admin-ajax.php. หากใช่ ให้ขยายและไปที่แท็บโพสต์ ที่นี่คุณสามารถระบุผู้กระทำผิดได้ ในกรณีของเรา ปลั๊กอิน "สวิตช์เดสก์ท็อป" จะใช้ไฟล์ admin-ajax.php และส่งคำขอไปยังเซิร์ฟเวอร์อย่างต่อเนื่อง นี่คือเวลาที่ต้องตัดสินใจว่าจะแทนที่ด้วยปลั๊กอินอื่นหรือลบออก

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

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

มีเพียงสองวิธีแก้ไขปัญหานี้ หรือปิดใช้งาน Heartbeat API/เปิดใช้งานในบางแห่งเท่านั้น

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

หากคุณมีข้อเสนอแนะหรือคำขอใด ๆ โปรดแสดงความคิดเห็นด้านล่าง

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

ไฟล์ admin-ajax.php คืออะไร?

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

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

สถานการณ์เดียวที่สำคัญสำหรับคุณในบริบทของ admin-ajax.php คือพยายามทำความเข้าใจว่าเหตุใดไฟล์นี้จึงทำงานช้าลงในการทดสอบ เว้นแต่คุณจะเป็นผู้ใช้ที่เชี่ยวชาญทางเทคนิค (เช่น ใน Pingdom) หรือคุณอาจเห็นคำขอจำนวนมากสำหรับไฟล์นี้ในบันทึกการเข้าถึงโฮสติ้ง

การปรากฏของ admin-ajax.php ในการทดสอบความเร็วและบันทึกการเข้าถึงมักเป็นผลมาจากสองสถานการณ์ที่แตกต่างกัน: สถานการณ์หนึ่งอยู่ที่ส่วนหน้าและอีกสถานการณ์หนึ่งอยู่ในส่วนหลัง เราจะพูดถึงเรื่องนี้ในภายหลัง

ปลั๊กอินอาจทำให้ admin-ajax.php ทำงานช้าลง

ปัญหายอดนิยมที่ผู้ใช้เผชิญในบริบทของ admin-ajax.php เกิดจากปลั๊กอินของบุคคลที่สาม โดยปกติจะมองเห็นได้ที่ส่วนหน้าและแสดงในการทดสอบความเร็ว นักพัฒนาใช้ไฟล์นี้หรือ AJAX เพื่อเพิ่มฟังก์ชันการทำงานให้กับปลั๊กอินของตน เพียงเพราะคุณเห็นคำขอไปที่ admin-ajax.php ไม่ได้หมายความว่าจะทำให้ไซต์ช้าลงเสมอไป AJAX จะโหลดหลังจากที่หน้าเว็บถูกนำเสนอ และบางคำขออาจโหลดแบบอะซิงโครนัส แต่นี่ไม่ได้หมายความว่านักพัฒนาทำการดาวน์โหลดอย่างถูกต้องและเขียนโค้ดที่มีประสิทธิภาพในแง่ของประสิทธิภาพเสมอไป

ด้านล่างนี้คือตัวอย่างวิธีที่เราวินิจฉัยการชะลอตัวอย่างรวดเร็วใน admin-ajax.php เราใช้ GTmetrix เนื่องจากช่วยให้เราตรวจสอบข้อมูลการโพสต์และการตอบกลับแต่ละรายการได้ น่าเสียดายที่ Pingdom ไม่อนุญาตให้เราดูคำขอข้อมูลในรูปแบบ คุณยังสามารถใช้ Google Chrome Devtools หรือ WebPageTest ได้

โหลดสูงใน admin-ajax.php เมื่อใช้ปลั๊กอิน Visual Composer

ด้านล่างนี้คือไซต์ WordPress ของเราที่เราพบปัญหาความล่าช้าที่สูงมากเมื่อใช้ admin-ajax.php ดังที่คุณเห็นจาก GTmetrix เวลาแฝงของคำขอไปยัง admin-ajax.php คือมากกว่า 8 วินาที “น้ำตก” ส่วนที่เหลือดูดี แต่เจ้าของสถานที่ต้องแก้ไขความล่าช้านี้

หากคุณคลิกที่คำขอ POST admin-ajax.php คุณจะเห็นแท็บสามแท็บต่อไปนี้: ส่วนหัว โพสต์ และการตอบกลับ เมื่อวิเคราะห์ปัญหาที่เรากำลังพิจารณา เราจะสนใจเฉพาะแท็บโพสต์และการตอบกลับเท่านั้น คำแนะนำสามารถดูได้ในแท็บการตอบกลับ เราเห็นว่าส่วนหนึ่งของคำขอเชื่อมโยงกับสคริปต์ vc_shortcodes-custom-css

การคัดลอกและวางอย่างรวดเร็วใน Google เผยให้เห็นว่าปัญหาเกิดจากปลั๊กอิน Visual Composer

ขั้นตอนต่อไปสำหรับผู้ใช้คือต้องแน่ใจว่าปลั๊กอิน Visual Composer เป็นเวอร์ชันล่าสุดอย่างสมบูรณ์ ถ้าใช่ คุณต้องติดต่อผู้พัฒนาปลั๊กอินและแจ้งปัญหากับ admin-ajax.php นี่เป็นปัญหาที่พบบ่อยจริงๆ โดยตัดสินจากโพสต์ใน Stack Overflow หากนักพัฒนาไม่สามารถแก้ไขได้ในปลั๊กอินของตน ก็จะมีปลั๊กอินทางเลือกหลายตัวที่ทำสิ่งเดียวกันอยู่เสมอ นั่นคือพลังของ WP ตัวอย่างเช่น หากคุณต้องการเครื่องมือสร้างเพจ คุณสามารถลองใช้ Beaver Builder หรือ Elementor ได้

เวลาแฝงสูงด้วย admin-ajax.php เนื่องจากปลั๊กอินแถบการแจ้งเตือน

ตัวอย่างที่สองที่เราพบเกิดขึ้นหลังจากติดตั้งปลั๊กอินของบุคคลที่สาม เราสังเกตเห็นว่าคำขอไปยัง admin-ajax.php เพิ่มขึ้นอย่างมาก

ขอย้ำอีกครั้ง หากคุณคลิกที่คำขอ POST ของ admin-ajax.php คุณจะสามารถสำรวจทุกอย่างโดยละเอียดได้ เราเห็นว่าข้อมูลมีสตริง “action=mtsnb_add_impression&bar_id=88&ab_variation=none”

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

หากคุณเป็นนักพัฒนา มีวิธีอื่นในการติดตามว่าปลั๊กอินใดที่อาจสร้างการตอบกลับ POST แต่เราพบว่าวิธีการที่อธิบายไว้ในบทความนี้มีประสิทธิภาพมาก

วิธีการโบราณในการกำหนดแหล่งที่มาของคำขอของ admin-ajax.php

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

ปัญหา CPU กับ admin-ajax.php ในแบ็กเอนด์

ปัญหาสำคัญประการที่สองคือ WordPress Heartbeat API ใช้ admin-ajax.php เพื่อทริกเกอร์การโทร AJAX จากเว็บเบราว์เซอร์ ซึ่งอาจนำไปสู่การใช้งาน CPU สูง คำขอ AJAX แต่ละรายการยังโหลดแบ็กเอนด์ WordPress เต็มรูปแบบ โดยเลี่ยงการแคชทุกรูปแบบ โดยทั่วไป คุณจะไม่เห็นสิ่งนี้ในการทดสอบความเร็ว นี่เป็นสิ่งสำคัญอย่างยิ่งที่ต้องทราบสำหรับผู้ที่ใช้โฮสติ้งที่ใช้ร่วมกันราคาถูก เนื่องจาก CPU มีพื้นที่ไม่มากนัก ปัญหานี้เคยเกิดขึ้นกับ HostGator มาก่อน

หนึ่งในสถานการณ์ที่คุณต้องระวังอย่างมากคือการบันทึกอัตโนมัติใน WordPress และมีแท็บที่เปิดอยู่ ตัวอย่างเช่น เราเปิดตัวโครงการใหม่บนเว็บไซต์ของเราและเปิดแท็บทิ้งไว้ ตามค่าเริ่มต้น Heartbeat API จะสำรวจไฟล์ admin-ajax.php ทุกๆ 15 วินาทีเพื่อทำการบันทึกอัตโนมัติ สามารถดูได้ในบันทึกการเข้าถึง หากเราเปิดแท็บทิ้งไว้หนึ่งวัน หนึ่งโพสต์สามารถสร้างคำขอได้ 5,760 คำขอต่อวัน

นั่นเป็นคำขอแบ็กเอนด์มากเกินไปสำหรับบุคคลหนึ่งคน ลองนึกภาพว่าจะเกิดอะไรขึ้นถ้าคุณมีบรรณาธิการหลายคนในไซต์ของคุณ คำขอเหล่านี้จะเพิ่มขึ้นแบบทวีคูณ เราพบสิ่งนี้ระหว่างการวิจัยกับ DARTDrones ซึ่งเราได้ช่วยขยายไซต์ WooCommerce สำหรับ Shark Tank มีการเรียก admin-ajax.php มากกว่า 4,100 ครั้งต่อวัน ในขณะที่มีผู้เยี่ยมชมเพียง 2,000 คน นี่ไม่ใช่อัตราส่วนคำขอต่อการเข้าชมที่ดีที่สุด การวิจัยของเราแสดงให้เห็นว่าคำขอส่วนใหญ่มาจากคอนโซล - สร้างขึ้นเนื่องจากผู้ดูแลระบบกำลังอัปเดตไซต์เพื่อเตรียมแสดงผล

มีวิธีตรวจจับปัญหาบางอย่างเกี่ยวกับการเรียก admin-ajax.php ในส่วนแบ็คเอนด์ เมื่อพูดถึงการบันทึกอัตโนมัติ การแก้ไข การล็อคบันทึก ฯลฯ ในการดำเนินการนี้ คุณจะต้องติดตั้งปลั๊กอิน Heartbeat Control

ปัจจุบันปลั๊กอิน Heartbeat Control ได้รับการติดตั้งบนไซต์มากกว่า 50,000 แห่งและมีคะแนน 5 จาก 5 คะแนน เป็นเวลา 2 ปีแล้วนับตั้งแต่มีการอัปเดต แต่ก็ยังใช้งานได้เหมือนเดิม เนื่องจาก Heartbeat API ยังไม่ได้รับการอัปเดตเช่นกัน

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

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

คุณยังสามารถใช้ปลั๊กอินพรีเมียม เช่น perfmatters เพื่อปิดฮาร์ทบีท เปลี่ยนความถี่ในการโพล และแก้ไขช่วงเวลาการบันทึกอัตโนมัติ

บทสรุป

อย่างที่คุณเห็นมีตัวเลือกที่ง่ายและรวดเร็วมากมายสำหรับการวินิจฉัยและแก้ไขปัญหากับ admin-ajax.php โดยทั่วไปแล้วจะปรากฏขึ้นเนื่องจากปลั๊กอินของบุคคลที่สามที่อาจขัดแย้งกันหรือมีโค้ดเบสที่ไม่ดี

คุณเคยประสบปัญหานี้บนเว็บไซต์ของคุณหรือไม่? หากเป็นเช่นนั้น โปรดแบ่งปันเรื่องราวของคุณ

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

วันนี้เราจะขยายธีมที่สองเล็กน้อยและปิดการใช้งานทรัพยากรจำนวนมากและไม่ใช่ทุกคนที่ต้องการกลไก WordPress ที่เรียกว่า ฮาร์ทบีท API.

ฮาร์ทบีท API— ฟังก์ชัน WordPress ที่ให้สิ่งต่าง ๆ เช่น:

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

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

ในความเป็นจริงสิ่งนี้จะแสดงเป็นคำขอคงที่โดยมีช่วงเวลา 15-30 วินาที (ขึ้นอยู่กับเวอร์ชันที่ติดตั้ง) ไปยังไฟล์เฉพาะไฟล์เดียว admin-ajax.php จากเกือบทุกหน้าของแผงการดูแลระบบ สถานการณ์จะแย่ลงหากคุณต้องการเปิดแท็บคอนโซลหลายแท็บพร้อมกัน: คำขอจะถูกส่งโดยอัตโนมัติจากแต่ละแท็บ ในความเป็นจริง, HeartBeat API เป็นกลไก WordPress มาตรฐานที่ใช้ทรัพยากรมากที่สุด.

เราจะปิดการใช้งานฟังก์ชันนี้ในวันนี้ ขอแนะนำให้ปิดการใช้งาน HeartBeat API สำหรับไซต์ WordPress ของคุณหาก:

• โดยทั่วไป ไซต์ของคุณมีทรัพยากรเพียงพอในบัญชีของคุณ ซึ่งสำคัญมาก ส่วนเกินเกิดขึ้นเฉพาะในขณะที่ทำงานในคอนโซลเท่านั้น;
• ไซต์นี้ได้รับการแก้ไขโดยคุณเป็นการส่วนตัวเท่านั้น(นั่นคือไซต์มีโปรแกรมแก้ไข 1 รายการ ไม่ใช่หลายรายการ)

ความสนใจ!โซลูชันนี้ไม่เหมาะกับทุกไซต์ ขึ้นอยู่กับธีมที่ติดตั้งบนไซต์ ปลั๊กอิน และการตั้งค่าแต่ละไซต์ คุณสามารถทดลองใช้ได้ และหากปรากฏว่าเข้ากันไม่ได้กับองค์ประกอบใดๆ ของไซต์หรือส่งผลต่อฟังก์ชันไซต์ที่สำคัญสำหรับคุณ คุณสามารถเปิดใช้งาน HeartBeat API ได้ตลอดเวลาโดยคืนการตั้งค่าก่อนหน้า

วิธีปิดการใช้งาน HeartBeat API

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

พาธไปยังไฟล์ function.php มีลักษณะดังนี้: /path_to_site_root/wp-content/themes/theme_name/functions.php

เพิ่มที่จุดเริ่มต้นของไฟล์หลังแท็ก

Add_action("init", "stop_heartbeat", 1); ฟังก์ชั่น stop_heartbeat() ( wp_deregister_script("heartbeat"); )

บรรทัดเหล่านี้ปิดใช้งาน HeartBeat สำหรับทั้งไซต์

ปลั๊กอินควบคุม HeartBeat

นอกจากนี้ยังมีวิธีแก้ปัญหาที่รุนแรงน้อยกว่าการปิดใช้งาน HeartBeat API โดยสิ้นเชิง มีให้โดยปลั๊กอินพิเศษ การควบคุมการเต้นของหัวใจ. ติดตั้ง เปิดใช้งาน และไปที่การตั้งค่า (เครื่องมือ -> การควบคุม HeartBeat) ในการตั้งค่า คุณสามารถเลือกตัวเลือกต่อไปนี้:

1. ว่าจะปิดการใช้งาน HeartBeat สำหรับทั้งไซต์หรืออนุญาตให้ใช้งานได้เพียงบางส่วนเท่านั้น เช่น สำหรับหน้าสำหรับแก้ไขและเผยแพร่โพสต์ในแผงการดูแลระบบ

2. ความถี่ของการร้องขอไปยังไฟล์ admin-ajax.php ตามค่าเริ่มต้นอาจเป็น 15 วินาที - เปลี่ยนค่านี้ เช่น เป็น 60 วินาที และด้วยเหตุนี้ ลดการใช้ทรัพยากรสำหรับการสืบค้นเหล่านี้ได้มากถึง 75%!

สิ่งสำคัญที่ต้องจำ

• ด้วยการปิดการใช้งาน HeartBeat API เราได้ปิดการใช้งานคุณสมบัติการบันทึกอัตโนมัติ บันทึกหน้าและโพสต์ที่แก้ไขเป็นระยะ (ตามความจำเป็น)

• เนื่องจาก HeartBeat API ถูกปิดใช้งานที่ระดับธีม (เทมเพลต) ของไซต์ ทันทีที่คุณเปลี่ยนธีม (เทมเพลต) HeartBeat API จะทำงานอีกครั้ง ขั้นตอนการปิดใช้งานจะต้องทำซ้ำสำหรับแต่ละธีมใหม่ที่คุณเริ่มใช้บนไซต์

• เช่นเดียวกับการอัปเดตธีมปัจจุบัน: หลังจากอัปเดตแล้ว จะต้องทำซ้ำขั้นตอนการปิดระบบ

เราหวังว่าคุณจะมีงานที่น่าพอใจ!

ฉันถูกบังคับให้สร้างโพสต์นี้ด้วยปัญหาที่เริ่มส่งผลกระทบต่อไซต์ของฉันมากขึ้นเรื่อยๆ ปัญหาคือการเปิดหน้าเว็บไซต์และทำงานในแผงผู้ดูแลระบบ พวกเขาเข้มแข็งและบ่อยครั้งจนยากที่จะเขียนแม้แต่ข้อความเล็กๆ น้อยๆ การเชื่อมต่อกับเซิร์ฟเวอร์ลดลงอย่างต่อเนื่อง โหลดสูงบน CPU ซึ่งหมายถึงเกินขีดจำกัดซอฟต์ที่เรียกว่าเกิดขึ้นอย่างต่อเนื่อง ฉันเริ่มได้รับข้อความอีเมลจาก Metrica และปลั๊กอิน Jetpack บ่อยมาก โดยระบุว่าไซต์ดังกล่าวมักใช้งานไม่ได้ แม้ในเวลาที่ฉันไม่ได้ดำเนินการก็ตาม กล่าวโดยสรุป ความสยองขวัญอันน่าสยดสยองเข้ามาครอบงำฉันอีกครั้งด้วยปัญหาความเร็วไซต์ และฉันก็ติดต่อฝ่ายบริการสนับสนุนที่โฮสติ้ง “Gino” ของฉันอีกครั้ง

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

ประการแรกการสนับสนุนโฮสติ้งดึงความสนใจของฉันไปที่คำขอจำนวนมาก /wp-admin/admin-ajax.php.“คำขอสร้างการดำเนินการในแผงการดูแลระบบของไซต์ ลักษณะการทำงานนี้เป็นเรื่องปกติหากปลั๊กอินตัวใดตัวหนึ่งทำงานไม่ถูกต้อง ปิดการใช้งานปลั๊กอินของไซต์ทีละรายการและตรวจสอบการทำงานของปลั๊กอิน หากคุณพบปลั๊กอินที่มีปัญหา ให้ลองอัปเดตหรือติดตั้งเวอร์ชันเสถียร หรือแทนที่ด้วยอะนาล็อกที่ไม่ก่อให้เกิดปัญหา”

มีปลั๊กอินที่ติดตั้งไว้ค่อนข้างมากบนเว็บไซต์ของฉัน และการตรวจสอบทีละปลั๊กอินนั้นเป็นปัญหามาก ดังนั้นฉันจึงให้ความสนใจกับลิงก์ที่ฝ่ายสนับสนุนด้านเทคนิคทิ้งไว้ให้ฉันสำหรับปลั๊กอิน การควบคุมการเต้นของหัวใจ. การติดตั้งและการตั้งค่าอื่นๆ ช่วยแก้ปัญหาของฉันได้!

บริการสนับสนุนด้านเทคนิคยังชี้ให้เห็นปัญหาอื่นและแนะนำให้ดำเนินการตามขั้นตอนเพื่อแก้ไขโค้ดในไฟล์ wp-cron.php แต่เกี่ยวกับปัญหานี้ในตอนท้ายของข้อความ

ทีนี้เรามาดูสาระสำคัญของเรื่องข้างต้นกันดีกว่า

Heartbeat API บน WordPress คืออะไรและจะจำกัดได้อย่างไร

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

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

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

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

ปิดการใช้งาน Heartbeat API โดยสมบูรณ์

สถานการณ์กรณียากนี้ ซึ่งฉันไม่อยากทำคือคุณต้องดำเนินการบางอย่างในไฟล์ function.php ของธีมของคุณที่ติดตั้งอยู่บนไซต์ในปัจจุบัน

Add_action("init", "stop_heartbeat", 1); ฟังก์ชั่น stop_heartbeat() ( wp_deregister_script("heartbeat"); )

แน่นอนว่าเมื่ออัปเดตธีมนี้หรือแทนที่ด้วยธีมอื่น คุณจะต้องดำเนินการนี้อีกครั้ง

ปลั๊กอิน Heartbeat Control และการตั้งค่า

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

4. การใช้การตั้งค่าสำหรับหน้าแผงผู้ดูแลระบบ

เพื่อความชัดเจน ผมขอชี้แจงดังนี้

1. ใช้ค่าเริ่มต้น - ใช้ Heartbeat API เป็นค่าเริ่มต้น
2. ปิดการใช้งานทุกที่ — ปิดการใช้งาน Heartbeat API ทุกที่
3. ปิดการใช้งานบนหน้าแดชบอร์ด — ปิดการใช้งาน Heartbeat API บนหน้าแดชบอร์ด (คอนโซล)
4. อนุญาต onli จากหน้าแก้ไขโพสต์ - ใช้ Heartbeat API เมื่อแก้ไขหน้าเท่านั้น

2. การปรับความถี่ของการร้องขอไปยังเซิร์ฟเวอร์

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

หลังจากทำการตั้งค่าแล้ว ให้บันทึกการเปลี่ยนแปลง

เนื่องจากการบันทึกการบันทึกอัตโนมัติระหว่างการแก้ไขยังคงเป็นฟังก์ชันที่ต้องการ (คุณสามารถลบการแก้ไขที่ไม่จำเป็นในภายหลังได้ด้วยการล้างด้วยปลั๊กอินพิเศษ) และการสูญเสียการบันทึกที่เกือบจะเสร็จสมบูรณ์ด้วยเหตุผลทางเทคนิคบางประการนั้นไม่เป็นที่พอใจ (อินเทอร์เน็ตหรือการเชื่อมต่อกับเซิร์ฟเวอร์หายไป ฯลฯ ) เป็นสิ่งที่ไม่พึงประสงค์อย่างมาก ดังนั้นการตั้งค่าสำหรับบล็อกแรกในฟิลด์สามารถตั้งค่าเป็นโหมด "ใช้ค่าเริ่มต้น" ได้ แต่จะเพียงพอที่จะทำการตั้งค่าในบล็อกที่สองเนื่องจากการตั้งค่าตัวจับเวลาความถี่คำขอเป็นไฟล์ admin-ajax.php . วี 60 วินาที จะลดการใช้ทรัพยากรสำหรับคำขอเหล่านี้ได้มากถึง 75%!

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

ในตอนต้นของบทความ ฉันพูดถึงว่าเจ้าหน้าที่ฝ่ายสนับสนุนทำให้ฉันสนใจอีกสาเหตุหนึ่งที่ทำให้เกิดความยากลำบากในการดำเนินงานไซต์ของฉัน เหตุผล -

กระบวนการที่ไม่ต้องการในไฟล์ wp-cron.php

ฝ่ายสนับสนุนด้านเทคนิคจากการค้นคว้าการทำงานของเว็บไซต์ของฉัน พบว่ามี "กระบวนการ wp-cron.php ถูกสังเกต" ในเว็บไซต์เหล่านั้น พวกเขาแนะนำ: "หากการเรียกใช้ไฟล์นี้ทำให้เกิดการโหลดที่ไม่แข็งแรงบนเซิร์ฟเวอร์ คุณสามารถปิดการใช้งานเหล่านี้ได้"

1. เมื่อต้องการทำเช่นนี้ในไฟล์การกำหนดค่า WordPress wp-config.phpเพิ่มบรรทัด:
   กำหนด('DISABLE_WP_CRON', 'จริง');
   คุณสามารถเพิ่มที่ไหนสักแห่งหลังจากติดตั้งภาษา เช่น หลังบรรทัด
   กำหนด('WPLANG', 'ru_RU');
2. วิธีแก้ไขปัญหาอื่นอยู่ในไฟล์นั้นเอง wp-cron.phpแสดงความคิดเห็นในบรรทัด: wp-cron.phpign_user_abort(true); ในการดำเนินการนี้ คุณต้องนำหน้าด้วยเครื่องหมายทับสองครั้ง มันจะออกมาดังนี้: //ignore_user_abort(จริง);บรรทัดนี้อยู่ในแถวที่ 12 ของไฟล์

นั่นคือทั้งหมดเพื่อน

(เข้าชม 304 ครั้ง, 1 ครั้งในวันนี้)