0212 | National Internet Exchange India

นั่งอ่านเรื่องอินเทอร์เน็ตแต่ละประเทศไปเรื่อยๆ พอดีไปเจอข้อมูลเกี่ยวกับ NIX (ศูนย์แลกเปลี่ยนข้อมูลภายในประเทศ) ของประเทศอินเดียมา น่าสนใจดี (สำหรับคนทำงานสายเครือข่ายอินเทอร์เน็ต)

ข้อมูลทั่วไป

  • NIXI ดำเนินการโดยรัฐบาลอินเดียเอง มี router อยู่หลายเขต (ตามขนาดประเทศ)
  • การออกนโยบายคำนึงถึง 3 ข้อ
    • ผู้ให้บริการรายใหญ่เป็นผู้ลงทุนโครงข่ายหลักๆ
    • ผู้ให้บริการรายเล็กต้องไม่ถูกทอดทิ้ง หรือเอารัดเอาเปรียบ
    • The policy should encourage domestic Content being hosted out of India (แปลแล้วแอบงง ว่าผลักดันให้ content ไปอยู่ต่างประเทศ???) แต่เป้าหมายคือทำให้ ISP ในอินเดียแปลงรูปแบบการเชื่อมต่อจากเช่าใช้ transit จากต่างประเทศ เป็นการเชื่อมต่อ peering ซึ่งมีราคาถูกกว่าแทน
  • ISP เชื่อมต่อ BGP session หา router ของ NIXI (ตามรูปแบบของ NIX ปกติ)
  • ISP ประกาศเฉพาะ IP ของตัวเองและลูกค้าตัวเองหา NIXI (ตามรูปแบบของ NIX ปกติ)

การคิดเงิน ตามการใช้งาน

  • คิดจากส่วนต่างปริมาณการใช้งาน ระหว่างข้อมูลเข้ากับออก
  • ถ้าออกมากกว่าเข้า (content อยู่เยอะ) ก็ได้ตัง ถ้าเข้ามากกว่าออก (customer อยู่เยอะ) ก็จ่ายตัง
  • เรทอยู่ที่ 5 INR ต่อ 1 GByte ของส่วนต่าง traffic เข้าออก
  • เช่น ISP A ส่งไปหา ISP B 100 GB แต่ ISP ส่งมาหา ISP A 5 GB หมายความว่า ISP B จะต้องจ่ายให้ ISP A 5 INR x (100 – 5) GB = 475 INR / ปัดเศษเป็น 500 INR (ประมาณ 250-280 บาท)
  • แต่ !!! ถ้าฝั่ง ISP นั้นเป็น IDC คือมีแต่ traffic ขาออก (แทบไม่มีการใช้งานขาเข้า) จะ “ไม่ได้” ค่าส่วนต่างของ traffic นี้ (เสียแต่ค่าเชื่อมต่อเข้า NIXI)
  • วิธีนับว่า ISP เป็น IDC คือ ดูสัดส่วน traffic ขาออก ต่อ traffic ขาเข้า ถ้ามากกว่า 5 : 1 ก็ถือว่าเป็น IDC

ค่าใช้จ่ายอื่นๆ

  • ค่าแรกเข้า 1000 INR ต่อจุดเชื่อมต่อ
  • ค่าสมาชิก 1000 INR ต่อปี
  • ค่าเชื่อมต่อตามขนาด link “ต่อปี” ดังนี้
    • 10 Mbps = 5,000 INR
    • 100 Mbps = 100,000 INR (ทำไมมันโดดจังวะ)
    • 1000 Mbps = 250,000 INR
    • 2000 Mbps = 375,000 INR
    • 10 Gbps = 500,000 INR (ปีละ 2.7 แสนบาท หรือเดือนละ 2 หมื่นกว่าบาทโดยประมาณ)

* แก้ไขใหม่ เมื่อกี้ดูตัวเลขผิด สรุปว่า 10 Gbps ถูกใช้ได้เลย เดือนละไม่กี่หมื่นบาทเอง สำหรับ IDC ฝั่ง content ไม่ต้องจ่ายค่า Data Transfer ด้วย (ตามเงื่อนไขด้านบน) ก็ทำให้ต้นทุนถูกลงไปอีก

ที่มา: Nixi

Tags: , , ,

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

หลังๆ มีงานต้อง 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: , , ,