Archive for the ‘PHP Coding’ Category

0211 | WordPress : ของที่ทั้งเจ๋งและกากในตัวเดียวกัน

Monday, July 20th, 2015 Posted in PHP Coding | No Comments »

หลังๆ มีงานต้อง optimize เว็บที่เป็น WordPress เยอะมากๆ ครับ แล้วก็เจอ programmer ที่ชอบทำอะไรพิสดารกับ wordpress มากๆ จนแบบ… อึ่มมมม นี่ไม่ได้รู้เลยใช่มั้ยว่า มัน กาก มาก

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

ความกากของ WordPress คือ ตัวมันเองใช้ cpu เปลืองมากๆ ครับ ต่อให้ลง WordPress เปล่าๆ ไม่ทำอะไรเลย แล้วลองยิงอัดดู “แค่” 5-10 request ต่อวินาทีก็ทำให้ server ที่มี CPU 4 core ใช้งาน cpu เต็ม 100% ได้แล้ว ตัวเลขนี้แปลงกลับมาเป็นจำนวน pageview ได้แค่วันละประมาณ 100,000 pageview หรือประมาณ 20,000 – 50,000 UIP แค่นั้นเอง

แล้วไม่ได้เพิ่งมาเป็นนะครับ เป็นมานานแล้วด้วย ดูได้จาก กระทู้นี้ ตั้งแต่เมื่อประมาณ 3 ปีที่แล้วโน่น…

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

ก็เลยเกิด Plugin มหาเมพขึ้นสำหรับ WordPress ครับ ด้วยแนวคิดที่ว่า ปกติเนื้อหาเว็บมันไม่ค่อยจะเปลี่ยนอยู่แล้ว เพราะงั้นก็ทำมันเป็น HTML ไปซะเลยก็สิ้นเรื่อง plugin ที่ว่าคือตระกูล cache ทั้งหลาย ที่นิยมใช้ก็ WP Super Cache, W3 Total Cache และจริงๆ มีอีกหลายตัวครับ

โดยวิธีการที่ Plugin พวกนี้ใช้คือ เมื่อ render หน้าเว็บเสร็จแล้วครั้งนึงก็สร้างไฟล์ cache ที่ path ใกล้เคียงกับ URL เดิม แล้วอาศัยความสามารถในการ rewrite (เปลี่ยนเส้นทาง URL) ของ server ส่งไปที่ไฟล์ cache ทันทีที่มีไฟล์ html ที่สร้างเสร็จแล้วอยู่ ทำให้การเข้าใช้งานหลังจากนั้นไม่ต้องเสียเวลาประมวลผลในฝั่ง PHP เลย แม้แต่นิดเดียว

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

  • บังคับใช้ Permalink แบบที่ไม่มีเครื่องหมาย ? อยู่ใน URL
  • ปิดระบบ comment ปกติของ WordPress ไปใช้พวก Disqus หรือ Facebook Comment แทน
  • Plugin ที่มีการนับสถิติทั้งหมด “ห้าม” ใช้โดยเด็ดขาด (อยากนับสถิติ เอา code ตัวนับของ google analytics ไปแปะใน theme แทนดีกว่า)
  • Plugin ‘Tracking Code’ ของพวกระบบโฆษณาก็ทำให้ cache ไม่ทำงาน นี่ก็ห้ามใช้เหมือนกัน
  • อย่าพยายามไปเรียกใช้ตัว ajax ของ WordPress บน Theme หรือ Plugin
  • อย่าเชื่อคำแนะนำของ wp touch ที่ให้ปิดแคชของ mobile ทิ้ง… คนเข้าจากมือถือสมัยนี้เยอะกว่า desktop แล้ว ไม่แคชก็ล่มพอดี
  • การเขียน code ระบบใหม่โดยไปดึง function ของ WordPress มาใช้ หรือไป include ไฟล์ wp-config.php มาใช้ในระบบตัวเองแล้วเรียกการทำงานด้วยวิธีของ WordPress ซึ่งไม่มี cache และไม่สามารถ cache ได้

แค่นี้ (เหรอ?) ก็ทำให้เว็บที่ใช้ WordPress รองรับคนเข้าได้หลักล้านต่อวันโดยไม่เปลืองทรัพยากรบนฝั่ง server แล้วครับ

Tags: , , ,

0148 | Concept ระบบจองตั๋ว

Sunday, February 17th, 2013 Posted in Database, PHP Coding, Web Server | No Comments »

จากกรณีเดี่ยวสิบระบบจองล่มอนาถ… ในหัวเลยลองร่างๆ ระบบ ticketing system ไว้อยู่พอประมาณครับ เงื่อนไขที่ร่างไว้ก็ประมาณนี้

ไม่รู้ทำจริงจะเน่ามั้ยนะ (ฮา) ออกแบบในหัวมาคร่าวๆ ยังไม่ได้ลงรายละเอียดเลยครับ ไม่รู้จะติดปัญหาอะไรยังไงบ้าง

  • เร็ว : แน่นอน ระบบต้องเร็วพอที่จะไม่ต้องเสียเวลารอในแต่ละขั้นตอนมาก
  • ชัวร์ : ล็อกที่นั่งระหว่างทำรายการได้ชัวร์จนกว่าจะ expire // ไม่อนุญาตให้เกิดการทำรายการจองที่นั่งซ้ำ
  • ปล่อยได้ : ที่นั่งที่ล็อกไว้รอทำรายการต้องมีกำหนด expire ถ้าทำรายการไม่เสร็จตามระยะเวลาก็ให้กลับคืนมาให้ระบบ
  • realtime : รายการผังที่นั่ง stream ดูกันสดๆ ได้เลยว่าที่นั่งไหนอยู่ในสถานะไหน (ajax streaming)

ส่วนประกอบของ service ก็จะได้ประมาณนี้

  • WebUI : ส่วนหน้าจอติดต่อ client อาจเป็น rest api หรือ full web เลยก็ได้
  • Payment Gateway Interface : ส่วนคุยกับระบบจ่ายเงิน (บัตรเครดิต, paypal, อื่นๆ)
  • Locking Services : เป็น In-memory service ที่ทำหน้าที่เก็บสถานะที่นั่งไว้ในแรม
  • Database : เอาไว้เก็บตัว transaction และ state จริงๆ ของที่นั่ง

ที่คิดไว้… ฝั่ง WebUI กับ Payment Gateway Interface นี่เขียนภาษาอะไรก็ได้ครับ ไม่ strict ส่วน locking service เป็น nodejs เนื่องจากต้อง listen http สำหรับ streaming ข้อมูลการ lock ที่นั่งส่งไปให้ client ด้วย … ส่วน database อยากใช้อะไรก็ใช้ไปฮะ

  • locking service สามารถรัน 1 zone ต่อ 1 หรือหลายรอบการแสดงได้ (แต่ไม่สามารถรันหลาย zone ต่อ 1 รอบการแสดงได้ เพราะจะทำให้มีโอกาสที่จะ lock ชนกัน) ทันทีที่รันให้โหลดข้อมูลผังที่นั่งและสถานะที่นั่งแต่ละที่จาก database มา map ไว้รอเลย
  • webui จะให้เลือกรอบการแสดง (ข้อมูลนี้ cache ได้ เพราะงั้นเข้าไม่ถึง database) แล้วจะไป fetch ข้อมูลผังที่นั่งจาก locking service พร้อมเปิด ajax streaming connection ทิ้งไว้เพื่อ update ผังที่นั่งสดๆ
  • พอ client คลิกยืนยันที่นั่งที่เลือก webui จะยิงคำสั่ง lock ไปให้ locking service
  • locking service จะ mark ที่นั่งนั้นเป็น pending payment ทันที พร้อมระบุเวลาที่ทำการ mark ด้วย โดยทำการ async save ลง database ด้วย พร้อม broadcast หา client ทุกตัวที่เชื่อมต่ออยู่ให้รู้ว่าที่นั่งนั้นๆ ไม่ว่างแล้ว
  • ถ้า locking service mark ที่นั่งไม่ผ่าน (update ชน หรือมี client ยิงคำสั่งที่นั่งมาชนกันพอดี) ให้แจ้งคนที่มาทีหลังว่าที่นั่งไม่ว่าง แล้วยิงให้ webui refresh ที่นั่งใหม่
  • webui เก็บข้อมูลอื่นๆ ของผู้ซื้อบัตร แล้ว redirect เข้า payment gateway ที่เจ้าตัวเลือก
    • ถ้าเป็น offline payment อย่าง counter service / atm / bill paymetn ก็ให้ยิงคำสั่งไปบอก locking service อีกรอบเพื่อแก้ไขสถานะเป็น offline payment required เพื่อไม่ให้ที่นั่งหลุด
    • ส่วน online payment ก็ทำรายการต่อไปจนจ่ายเงินสำเร็จ ยืนยันยอดเสร็จ webui ก็ update transaction ลง database ไปเลย แล้วยิงคำสั่งบอก locking service ว่าที่นั่งจองเรียบร้อยแล้ว ขึ้นสถานะเป็น complete ได้ หรือถ้า transaction fail ก็ยิงไปบอกให้ unlock ที่นั่ง
  • locking service ต้องทำ timer รอไว้ (setTimeout) สำหรับที่นั่งที่เพิ่ง mark pending payment ว่าภายใน X นาทีถ้ายังไม่เปลี่ยนสถานะให้ unlock ที่นั่ง <– อันนี้ต้องการความสามารถของ node.js เต็มๆ

สรุปแล้ว ทั้งระบบจะมี query database ประมาณนี้

  • ตอน start locking service ครั้งแรก query หาผังที่นั่ง + สถานะที่นั่ง
  • ตอนคนเลือกรอบการแสดงครั้งแรกๆ ที่ยังไม่ติด cache
  • locking service update สถานะที่นั่งเข้าฐานข้อมูล (free, pending payment, offline payment, completed)
  • webui update ข้อมูลลูกค้า
  • webui update ข้อมูล transaction

ต่อ 1 การจองก็จะมี query สามอันหลัง ประมาณ 7-8 query โดยไม่จำเป็นต้องทำ lock ที่ฝั่ง database ให้ระบบค้างเลย

จุดอ่อนใหญ่สุดของระบบนี้อยู่ที่ตัว locking service ที่ถ้ามันล่มก็จะจองตั๋วในรอบนั้นไม่ได้เลย รองลงมาก็การที่ยังต้อง query เข้า database เกือบสิบครั้งต่อ 1 การทำรายการจองซึ่งอาจเกิดคอขวดที่ database ได้ อาจแก้ได้ด้วยการแยก database ข้อมูลลูกค้ากับข้อมูลการจองออกจากกัน (สิ้นคิดมาก 555)