# After define( 'DB_COLLATE', '' );
if(!defined('WP_REDIS_PREFIX')){
define('WP_REDIS_PREFIX', substr(md5(DB_NAME), 0, 6) . '_');
define('WP_REDIS_MAXTTL', 86400);
}

และแถมด้วยอีกคำสั่งก็ค่อ MAXTTL ที่ช่วยกำหนดเวลาของแคช จากค่า Default = 3600 เป็น 86400 (หน่วยเป็นวินาที) เพื่อเพิ่มประสิทธิภาพของแคชครับ

ครอสเรียน WordPress ออนไลน์ฉบับมืออาชีพ จะสอนเกี่ยวกับระบบ WordPress อย่างละเอียด ตั้งแต่เริ่มต้นแบบมือใหม่ จนถึงระบบแบบมืออาชีพ ซึ่งประกอบไปด้วย 3 บทเรียนหลักๆ ดังนี้

1. WordPress Basic – จะสอนเกี่ยวกับระบบพื้นฐานการสร้างเว็บไซต์ด้วย WordPress ตั้งแต่แรก จนคุณมีเว็บไซต์เป็นของตัวเองได้ สอนทั้งเช่า Cloud Server ติดตั้งระบบ WordPress สอนทำเว็บไซต์ขายสินค้าออนไลน์ สอนติดตั้ง Theme สวยๆ Plugin ที่ทำให้เว็บไซต์ของคุณดูหรูหรามีราคา
2. WordPress SEO & Google PageSpeed Insights – สอนการทำ SEO บนระบบเว็บไซต์ที่สร้างขึ้นด้วย WordPress CMS และสอนทำคะแนน Google PageSpeed Insights ให้อยู่ในระดับ 90 – 100 ทั้งใน Desktop และ Mobile
3. WordPress Security – สอนเซตระบบ WordPress ให้ปลอดภัย ไม่โดนแฮก ใครที่มีปัญหา WordPress โดนแฮก ต้องเรียนครอสนี้แล้วคุณจะรู้วิธีการป้องกันแฮกเกอร์เจาะระบบเว็บไซต์ของคุณ (ใช้ได้กับระบบ CMS หรือ Script อื่นๆอีกด้วย)

จากกราฟ MRTG: ปัญหาอยู่ที่ Traffic มีเข้ามาจำนวนมาก (จาก Facebook Post) และทำให้ CPU ถูกใช้งานไปเกือบๆ 100% และ Load สูงมากๆ แถม RAM ก็หมดอีก โดย Space ที่ลูกค้าใช้งานอยู่คือ 4 vCore CPU และ 8GB RAM ครับ ส่วนซอฟต์แวร์ที่ใช้งานคือ Apache + Nginx, PHP (With Opcache) & MySQL และเว็บ WordPress นี้ไม่ต้องการใช้งาน Plugin Cache ข้อมูลหน้าเว็บ เพราะว่าต้องการสถิติที่แบบ Real-Time ครับ

หลังจากที่เซิฟเวอร์โหลดสูงไม่มีท่าทีว่าจะหยุด ทางผมจึงได้ใช้ CloudFlare Cache เข้ามาช่วย (https://xvlnw.com/topic/178) แต่ก็ไม่เป็นผลสำเร็จ เนื่องจากการแคชของ CloudFlare ยังต้องมาเรียกข้อมูลที่เซิฟเวอร์อยู่ และเซิฟเวอร์ไม่สามารถส่งข้อมูลได้เร็ว เว็บก็ยังคงโหลดช้าเหมือนเดิม ในช่วงที่เอา CloudFlare มาช่วย จะเห็นได้จากกราฟ Traffic ด้านบน ทีมี Traffic และ New TCP Connection ขาดหายไป แต่นั่นก็ไม่ทำให้ CPU, Load ลดลงแต่อย่างใด

ผมจึงคิดได้ว่าอาจจะเกิดจาก Plugin: WP-PostViews (https://th.wordpress.org/plugins/wp-postviews/) ที่เป็น Plugin เกี่ยวกับการเก็บสถิติการเข้าชมหน้าโพสต่างๆ ก็เลยใช้ตัวช่วย phpMyAdmin ในการเข้าไปตรวจสอบสถิติในการใช้งาน MySQL เพราะเห็นว่าใน SSH ใช้คำสั่ง top -c แล้วเห็นว่ามี process ของ MySQL ใช้งาน CPU สูงอยู่ตลอดเวลา จึงได้ผลตามภาพ

ก็แปลกใจอยู่ เพราะว่าการอัพเดต views นั้นจะใช้คำสั่ง update เป็นหลัก แต่ % ของการใช้คำสั่ง update นั้นแทบจะไม่มีเลย แต่เป็นการใช้งาน select ซะมากกว่า เพราะฉะนั้น ปัญหาอาจจะไม่ได้มาจาก WP-PostViews แล้วแน่นอน จึงได้ใช้ phpMyAdmin ตัวเดิมนี่แหละ ดูคำสั่ง Query ที่ค้างอยู่ใน Processes ก็ถึงบางอ้อกันเลยทีเดียว เพราะว่ามีการใช้คำสั่ง select มาจากตาราง wp_most_popular โดยการใช้คำสั่ง where post_id = ‘xxxx’ เพื่อเรียกข้อมูลให้ตรงกับ post นั้นๆ เยอะมาก เพราะฉะนั้น ปัญหามันจะต้องมาจาก WP Most Popular อย่างแน่นอน

จึงได้เข้าไปส่องในตาราง และดูโครงสร้างของตาราง ก็พบว่า post_id ไม่ได้มีการทำ Indexing ไว้ ทำแต่ Primary Key ที่เป็นฟิลล์ id เท่านั้น, ก็เพื่อความแน่ใจว่ามันเป็นแบบนี้ตั้งแต่ทีแรก ก็เลยไปโหลด Plugin: WP Most Popular 0.3.1 ซึ่งเป็นเวอร์ชั่นล่าสุด ณ เวลาที่เขียนบทความนี้นะครับ เอามาแงะดูและผลที่ได้ตามภาพ

OMG! มันไม่ได้ทำ Indexing ให้กับฟิลล์ post_id จริงๆด้วย ผมก็เลยทำ Indexing ด้วยตัวเอง ผ่านทาง phpMyAdmin นั่นแหละ แล้วผลเป็นอย่างไรหละ? ก็ตามภาพกราฟ MRTG ที่โพสไปตอนแรกนั่นเอง การใช้งาน CPU ลดลง, และ Load ก็ลดลง มีการคืน RAM กลับมาให้เหลือไว้ใช้งานได้อีก รวมถึงการที่ Traffic Load เพิ่มมากขึ่นอีกด้วย เพราะฉะนั้น สำหรับใครที่ใช้งาน WP Most Popular อยู่แล้ว แนะนำให้ไปทำ Indexing ในฟิลล์ post_id กันด้วยนะครับ (ออกแบบ DB ดี มีชัยไปกว่าครึ่ง)

หมายเหตุ: สำหรับ WordPress ที่ใช้งาน Plugin Cache ข้อมูลต่างๆ จะไม่เจอปัญหานี้นะครับ (รวมถึงใช้ CloudFlare เข้ามาช่วยแคชได้ด้วย) เพราะว่าการ Query มันก็เอามาเก็บเป็นแคช และเวลาเรียกครั้งต่อไปก็ไม่ได้ไป Query ใหม่อยู่แล้ว จนกว่าจะเคีลยร์แคช หรือแคชหมดเวลานั่นแหละ ก็อย่างที่บอกไปข้างต้นว่าเว็บนี้ไม่ต้องการแคชข้อมูลนั่นเอง มันก็เลยเจอปัญหาอย่างที่เห็นครับ