โดยค่า default เราจะไม่สามารถติดตั้ง open-vm-tools ผ่านคำสั่ง yum ใน CentOS 6 ได้ครับ สำหรับคนที่ใช้งาน VMware อาจจะมีปัญหาปวดหัวกับการติดตั้ง VM Tools จากตัว Esxi เองอยู่บ้าง การใช้งาน open-vm-tools นั้นจะช่วยให้เราลดปัญหาตรงนี้ไปได้เยอะเลย
# Open VM Tools - CentOS 6 yum --enablerepo=extras install epel-release yum install -y open-vm-tools service vmtoolsd start chkconfig vmtoolsd on
เนื่องจากมีลูกค้าของทาง CloudHost ได้ใช้บริการ Cloud Server และในส่วนของ Script ได้ใช้งาน WordPress CMS และ Plugin: WP Most Popular (https://th.wordpress.org/plugins/wp-most-popular/) ซึ่ง ณ วันที่เขียนบทความ จะเป็นตัว WP Most Popular 0.3.1 นะครับ
จากกราฟ 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 ใหม่อยู่แล้ว จนกว่าจะเคีลยร์แคช หรือแคชหมดเวลานั่นแหละ ก็อย่างที่บอกไปข้างต้นว่าเว็บนี้ไม่ต้องการแคชข้อมูลนั่นเอง มันก็เลยเจอปัญหาอย่างที่เห็นครับ
สำหรับ DirectAdmin Build-in จะไม่มี driver mssql มาให้ ต้องติดตั้งเสริมเองนะครับ โดยเราจะใช้ตัว FreeTDS เข้ามาช่วยครับ
เกี่ยวกับ FreeTDS – http://www.freetds.org/userguide/what.htm
วิธีการติดตั้ง:
ให้ทำการล็อคอินเข้าไปที่ SSH ของเซิฟเวอร์ที่ต้องการติดตั้ง และใช้คำสั่งติดตั้ง FreeTDS
cd /root wget ftp://ftp.freetds.org/pub/freetds/stable/freetds-patched.tar.gz tar -xvzf freetds-*.tar.gz cd freetds-* ./configure --prefix=/usr/local/freetds make make install
ถ้าโหลดไม่ได้ ให้ตรวจสอบลิงก์โหลด Stable Version ได้ที่เว็บไซต์ http://www.freetds.org/
หลังจากนั้น ไปที่ Path /usr/local/directadmin/custombuild/configure/ap2/ แก้ไขไฟล์ PHP Config ตามเวอร์ชั่นที่เราใช้งานอยู่ เช่น หากใช้ PHP 5.6 อยู่ ก็แก้ไขไฟล์ configure.php56 หากใช้หลายเวอร์ชั่น ก็แก้ไขให้ครบนะครับ โดยการเพิ่มคำสั่งด้านล่างนี้ลงไปก่อนบรรทัดสุดท้าย
--with-mssql=/usr/local/freetds \
หรือจะเพิ่มลงไปบรรทัดสุดท้าย ให้เอา \ ออกครับ
หลังจากแก้ไขไฟล์ PHP Config ครบแล้ว ให้ทำการ Build php ตามคำสั่งนี้
cd /usr/local/directadmin/custombuild ./build clean ./build php d
ตรวจสอบความถูกต้อง
php -m|grep mssql mssql
เป็นอันเสร็จครับ
สำหรับผู้ที่ใช้งาน CloudFlare และเปิดใช้งาน SSL ด้วย และอยากให้พิมพ์ URL แบบไม่มี SSL และเด้งไปหน้าที่เป็น SSL ทุกครั้ง สามารถสร้าง Page Rules ได้ตามรูปด้านล่างนี้ครับ
1. ล็อคอินที่ CloudFlare เลือกโดเมน และไปที่เมนู “Page Rules” จากนั้นคลิกที่ “Create Page Rule”
2. ใส่ URL ของโดเมนเรา และตามด้วย /* ด้านหลัง และเลือก Always Use HTTPS จากนั้นคลิกที่ “Save and Deploy”
3. จากนั้นก็จะได้ตามรูปด้านล่างนี้ เป็นอันเสร็จสิ้น
เชื่อว่าหลายๆท่านคงจะเคยได้ยิน CloudFlare ในที่นี้ผมจะเรียกสั้นๆว่า CF นะครับ โดยตัวมันเอง สามารถที่จะใช้งานได้ฟรี แถมยังมี SSL ให้ฟรี และปัจจุบันก็รองรับ HTTP 2 โดยที่เราไม่ต้องทำอะไรที่เซิฟเวอร์จริงๆเลย หรือแม้ว่าเซิฟเวอร์จริงๆของเราจะรองรับแค่ HTTP 1.0/1.1 หากเราไปใช้บริการ CF เราก็จะได้ใช้ HTTP 2 กันเลยฟรีๆ
แต่บทความนี้จะเจาะลึกลงไปยังการ Caching ข้อมูลในเว็บของเราระดับโหด ซึ่งหากเราใช้ CF โดยไม่ได้ปรับแต่งอะไรมาก จากที่ตรวจสอบพบว่ายังมี Traffic เข้ามาเรียกข้อมูลในหน้าเว็บไซต์ตลอดเวลา เพื่อให้เกิดความ Real-Time แต่ในบางครั้ง หน้าเว็บไซต์ของเราไม่ได้มีเนื้อหาอัพเดตอยู่อย่างสม่ำเสมอ หรือเนื้อหาอัพเดตตลอดเวลา อาจจะเป็นเว็บไซต์แนวๆอ่านข้อมูลซะมากกว่า เป็นต้น การ Caching ในบทความนี้จึงเหมาะกับเว็บประเภทนี้มากกว่านะครับ สำหรับเว็บบอร์ด หรือเว็บไซต์ที่ต้องอัพเดตเนื้อหาแบบ Real-Time อาจจะไม่เหมาะกับวิธีการที่ผมจะกล่าวต่อไปนี้ครับ
ก่อนอื่นเรามาดูจากกราฟ MRTG ที่ผมได้ทดสอบระหว่าง Caching กับไม่ได้ Caching แต่ยังใช้ CloudFlare (CF) มาดักไว้ข้างหน้าอยู่นะครับ ไม่ได้เข้ามาตรงๆที่เซิฟเวอร์ ผลปรากฏดังกราฟด้านล่างนี้ครับ
อธิบายกราฟ MRTG: ช่วงที่กราฟสูงๆ นั่นคือการที่เราไม่ได้ทำ Caching แต่ยังใช้บริการ CloudFlare อยู่ครับ ส่วนช่วงที่กราฟต่ำๆ คือการตั้งค่า Caching ไว้ที่ CloudFlare แล้วครับ
ส่วนด้านล่างนี้จะเป็นกราฟฝั่งของทาง CloudFlare ตอนที่เราทดสอบการแคช และไม่แคช ในเวลาเดียวกันนะครับ
สำหรับรูปด้านล่าง จะเป็น Bandwidth ที่อยู่กับทาง CloudFlare และไม่ได้หลุดเข้ามาที่เซิฟเวอร์ตรงๆ (ข้อมูลจะเป็น 24 ชั่วโมงล่าสุดนะครับ)
วิธีการตั้งค่า Caching:
การตั้งค่า Caching นั้น คงต้องอธิบายว่าแต่ละเว็บไซต์คงไม่เหมือนกัน เพราะว่าเราจะต้องมีบางหน้า ที่ต้องการข้อมูลที่ Real-Time เช่น หน้าเข้าสู่ระบบ (Login) ในที่นี้ผมจะยกตัวอย่าง WordPress CMS ที่จะเห็นภาพได้ชัด และเชื่อว่าหลายๆคนก็คงจะเคยใช้กันอยู่แล้วนะครับ ข้อมูลที่ไม่ได้ต้องการ Real-Time ก็คือข้อมูลหน้าเว็บไซต์ พวก Post, Page, Category, Tags และข้อมูลที่ต้องการความ Real-Time ก็คือ /wp-admin หรือระบบหลังบ้านของ WordPress เวลาเรา Login หรือเข้าไป Management ต่างๆ ต้องการข้อมูลที่ Real-Time เสมอ
หากเข้าใจด้านบนนี้แล้ว เราก็จะรู้ว่าเราควรจะตั้งค่าให้ Caching ข้อมูลอย่างไรนะครับ วิธีการตั้งค่า ให้เราเข้าไปยังโดเมนนั้นๆของเราใน CloudFlare และไปที่เมนู “Page Rules” สำหรับ Package Free เราจะสามารถสร้าง Page Rules ได้ทั้งหมด 3 Rules ด้วยกัน ส่วนตัวเสียเงินอันนี้ผมไม่รู้ว่าได้เท่าไรนะครับ (ขอข้ามไป)
การเรียบลำดับ Page Rules คือ “อันบนสุด สำคัญสุด และจะไม่ทำอันต่อไป หากเข้าเงื่อนไขอันใดอันหนึ่ง” การตั้งค่า WordPress จึงตั้งค่าได้ตามนี้ครับ
Bypass : ไม่ทำแคช ให้วิ่งเข้าหาเซิฟเวอร์ตรงๆ
Cache Everything : ทำการแคชทุกๆอย่าง
สำหรับบทความนี้ก็คงขอจบเท่านี้นะครับ การนำเอาไปใช้งาน ก็ขึ้นอยู่กับตัวเว็บไซต์ของท่านด้วย ใช้ Script อะไร? และจะนำเอาไปประยุกต์ใช้งานให้เกิดประโยชน์ได้อย่างไรครับ 🙂
โดยค่า Default ของตัว Control Panel ที่มีชื่อว่า DirectAdmin (DA) มันจะไม่มี SSL มาให้ และ Port ที่ใช้สำหรับ Login ก็คือ :2222 นั่นเอง
ปัจจุบัน DA รองรับการใช้งาน Let’s Encrypt ซึ่งเป็น SSL ฟรี สามารถขอ SSL ได้ผ่าน DA เลย การติดตั้ง SSL ให้หน้า DA Login จึงไม่ต้องเสียเงินอีกต่อไป แถมได้กุญแจสีเขียวๆอีกด้วย
สำหรับท่านที่ต้องการใส่ SSL ให้หน้า Login เพื่อป้องกันการ Sniff User & Pass สามารถทำได้ดังนี้ (Custombuild 2.0)
cd /usr/local/directadmin/scripts ./letsencrypt.sh request your.hostname.com 4096
โดยแก้ไข your.hostname.com ให้เป็น hostname ของคุณ ต้องตรงกับ hostname ใน server ด้วยนะครับ
หากในขั้นตอนนี้ไม่ผ่าน ให้ทำการเพิ่ม DNS A Record ดังนี้
your.hostname.com www.your.hostname.com mail.your.hostname.com pop.your.hostname.com smtp.your.hostname.com ftp.your.hostname.com
หลังจาก req SSL ผ่านเป็นที่เรียบร้อยแล้ว รอประมาณ 1 นาที ลองทดสอบเข้า URL https://your.hostname.com หรือจะลอง https://your.hostname.com:2222 ก็ได้ จะต้องขึ้นรูปกุญแจสีเขียวๆแล้วนะครับ
จากนั้น ให้เราตั้งค่า DirectAdmin ให้ทำการ Redirect ไปหน้า Login ที่มี SSL เสมอ โดยตั้งค่าตามนี้
cd /usr/local/directadmin/conf perl -pi -e 's/SSL=0/SSL=1/' directadmin.conf echo "carootcert=/usr/local/directadmin/conf/carootcert.pem" >> directadmin.conf echo "force_hostname=your.hostname.com" >> directadmin.conf echo "ssl_redirect_host=your.hostname.com" >> directadmin.conf /etc/init.d/directadmin restart
หลังจากนั้น เวลาเราพิมพ์ชื่อโดเมนที่อยู่ในระบบ โดเมนอะไรก็ได แล้วตามด้วย :2222 ระบบ DA ก็จะทำการ Redirect ไปยัง URL: https://your.hostname.com:2222 เสมอๆ เพราะฉะนั้น การเลือกโดเมนมาทำเป็น hostname อาจจะต้องคิดซักหน่อย ว่าจะเอาโดเมนไหนนะครับ
สำหรับการเข้า WebApps อื่นๆก็สามารถใช้งาน SSL ได้ด้วย เช่น https://your.hostname.com/phpMyAdmin สำหรับเข้าจัดการ Database ผ่านระบบ phpMyAdmin และ https://your.hostname.com/webmail สำหรับใช้จัดการ Email ผ่านเว็บไซต์
นอกจากนี้ยังรวมถึงการ FTP, SMTP, POP3 ก็จะสามารถใช้งาน SSL และ TLS สำหรับการรับส่งข้อมูลแบบเข้ารหัสได้ ปลอดภัย และไม่โดน Sniff ข้อมูลระหว่างการรับส่งกันด้วยครับ
ตัวอย่าง DirectAdmin ที่ใช้ SSL สำหรับ Login ของทาง CloudHost.in.th
ลิงก์เกี่ยวข้อง: https://help.directadmin.com/item.php?id=15
<IfModule mod_headers.c> Header set X-XSS-Protection "1; mode=block" Header always append X-Frame-Options SAMEORIGIN Header set X-Content-Type-Options nosniff </IfModule>
HTTPS (Hypertext Transfer Protocol Secure) หรือการเข้าถึงเว็บไซต์ด้วยความปลอดภัยจากการเข้ารหัสในการรับส่งข้อมูล เราจะเห็นเว็บไซต์ใหญ่ๆจะมี URL ขึ้นต้นด้วย https:// ไม่ว่าจะเป็น Facebook, Google, Yahoo, Bing, Microsoft, Amazon, หรือเว็บไซต์ธนาคาร, เว็บไซต์ที่ทำธุรกรรมการเงินต่างๆ ต่างก็ต้องใช้ SSL (Secure Sockets Layer) ในการเข้ารหัสข้อมูลระหว่างการรับส่งด้วยกันทั้งนั้น เพื่อให้ข้อมูลถึงผู้รับและผู้ส่งอย่างปลอดภัย และมั่นใจได้ว่าไม่มีใครสามารถดักอ่านข้อมูลระหว่างทางการรับส่งได้
จากที่กล่าวมานั้น แน่นอนว่ามันต้องมีประโยชน์และมีความสำคัญอย่างมาก แต่ก็มี Webmaster บางกลุ่มที่แสดงความคิดเห็นถึงการใช้งาน HTTPS ว่ามันจะทำให้เว็บโหลดช้า ซึ่งหากเราวิเคราะห์ตามเหตุผล ก็จริงอยู่ที่จะทำให้ช้าขึ้น เพราะว่าต้องมีขึ้นตอนการเข้ารหัสและถอดรหัส (Encode,Decode) แต่หากเราเทียบกับทรัพยากรฮาร์ดแวร์เซิฟเวอร์ในปัจจุบันแล้วนั้น เรียกได้ว่าแทบไม่ส่งผลอะไรกับความช้าของการโหลดหน้าเว็บไซต์เลย ซึ่งต้องขอบอกเลยว่า เอาเวลาไปปรับโครงสร้างส่วนของ Content ให้เร็วแรงจะดีกว่ามากังวลเรื่อง SSL ช้าจะดีกว่ามากๆเลย หากใครมีความคิดเห็นใดๆสามารถแสดงความเห็นกันได้เลยครับ
สำหรับท่านที่ไม่ถนัดใช้งานทางด้าน Command Line ไม่ว่าจะเป็น nano, vi และอื่นๆ สามารถใช้คำสั่ง “nmtui” เพื่อเรียก GUI ขึ้นมาปรับตั้งค่า Network ได้ตามใจชอบเลยครับ หลังจากที่ลองใช้งานแล้วก็สะดวกไปอีกแบบครับ
สืบเนื่องจากบทความ “.htaccess คำสั่ง Redirect HTTP ไปยัง HTTPS” สำหรับเว็บไซต์ที่ขับเคลื่อนโดย WordPress เราสามารถใช้งาน Plugin ที่มีชื่อว่า “SSL Insecure Content Fixer” สำหรับช่วยแก้ไข URL และ Link ต่างๆภายในเว็บไซต์ของเราให้กลายเป็น https:// ได้ทั้งหมดเลยนะครับ โดยไม่จำเป็นที่จะต้องเข้าไปแก้ไข Database หรือแก้ไขการตั้งค่าใดๆของระบบ WordPress เลย เพียงแค่ติดตั้งตัว Plugin ตัวนี้ และทำการ Active แล้วลองเข้าเว็บไซต์ของเราด้วย https:// แล้วก็ลอง View Source Code ดูก็ได้ครับ
อย่างไรก็ตาม SSL Insecure Content Fixer ไม่ได้ทำการ Auto Redirect จาก HTTP > HTTPS ให้นะครับ เราก็สามารถใช้ .htaccess ช่วยทำการ Redirect ได้นั่นเอง
ดาวน์โหลดปลั๊กอิน: https://th.wordpress.org/plugins/ssl-insecure-content-fixer/