เว็บเร็วขึ้น โตได้โดยไม่จ่ายเกินจำเป็น ตอนที่ 1: คนใช้เยอะต้องวัดอะไร ก่อนซื้อเครื่องเพิ่ม

ภาพปกสร้างด้วย AI เพื่ออธิบายร้านสมมติ ไม่ใช่ภาพระบบที่ติดตั้งหรือผลทดสอบจริง

ลูกค้ารอหน้าสั่งซื้ออยู่ 5 วินาที แต่กราฟ CPU ยังไม่เต็ม ถ้าเริ่มแก้ด้วยการเพิ่มเครื่อง เราอาจจ่ายเงินให้ระบบที่รอฐานข้อมูลเหมือนเดิม ผมจะเริ่มจากระบุให้ได้ว่าลูกค้ากำลังรออะไร และคำว่า “รองรับคนใช้เยอะ” หมายถึงงานชนิดไหนในช่วงเวลาใด

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

คนสมัคร คนออนไลน์ และคำขอ เป็นคนละจำนวน

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

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

สูตรสั้นที่ช่วยตั้งคำถาม ไม่ได้ใช้รับประกันขนาดระบบ

Little’s Law เชื่อมค่าเฉลี่ยของงานที่อยู่ในระบบ อัตรางานที่ผ่านระบบ และเวลาที่งานอยู่ในระบบ ภายใต้เงื่อนไขของระบบและช่วงวัดที่สอดคล้องกัน เขียนว่า L = λW ได้ โดย L เป็นจำนวนงานเฉลี่ย λ เป็นอัตรางานเฉลี่ย และ W เป็นเวลาเฉลี่ย ห้ามนำ p95 มาใส่แทนค่าเฉลี่ยแล้วเรียกผลนั้นว่ากำลังรองรับสูงสุด

สมมติ API หนึ่งรับและทำงานจบได้เฉลี่ย 100 คำขอต่อวินาที ใช้เวลาเฉลี่ย 0.25 วินาทีต่อคำขอ ในช่วงที่ไม่มีงานสะสมเพิ่มต่อเนื่อง จำนวนคำขอเฉลี่ยภายในขอบเขตนั้นจึงเป็น 25 คำขอ ถ้าเวลาเฉลี่ยกลายเป็น 1 วินาทีที่อัตราเดิม จำนวนเฉลี่ยจะเป็น 100 คำขอ ระบบต้องมีที่ให้รอเพิ่ม แม้จำนวนลูกค้าจะเท่าเดิม

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

ให้หน้าสินค้ากับการยืนยันคำสั่งซื้อมีคำว่าเสร็จคนละแบบ

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

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

ค่าเฉลี่ยอาจซ่อนคนที่รอนานที่สุด

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

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

สำหรับหน้าเว็บ Core Web Vitals ช่วยดูประสบการณ์จริงด้านการแสดงเนื้อหาหลัก การตอบสนองต่อการโต้ตอบ และความนิ่งของหน้า ใช้ข้อมูลผู้ใช้จริงหรือ RUM ควบคู่กับการทดสอบในห้องทดลอง การรัน Lighthouse ครั้งเดียวบนเครื่องแรงไม่ได้บอกว่ามือถือของลูกค้าทุกพื้นที่ลื่นแล้ว เกณฑ์และวิธีประเมินควรตรวจตามเอกสารปัจจุบันของ web.dev

เอกสาร web.dev ที่ตรวจสำหรับชุดนี้กำหนดเกณฑ์ “ดี” ของ LCP ซึ่งวัดการแสดงเนื้อหาหลักไว้ไม่เกิน 2.5 วินาที INP ซึ่งวัดการตอบสนองต่อการโต้ตอบไม่เกิน 200 มิลลิวินาที และ CLS ซึ่งวัดการขยับขององค์ประกอบบนหน้าโดยไม่คาดหมายไม่เกิน 0.1 โดยประเมินที่ p75 แยกมือถือกับเดสก์ท็อป นี่คือเกณฑ์ของตัวชี้วัด ไม่ใช่ผลวัดร้านสมมติหรือเป้าสำเร็จของคำสั่งซื้อที่ตกลงแล้ว

เวลารอไบต์แรกหรือ TTFB ช่วยวินิจฉัยการรับข้อมูล แต่ไม่ใช่ Core Web Vital อีกตัว ส่วน Total Blocking Time หรือ TBT ที่ใช้วินิจฉัยใน Lighthouse ไม่ใช่ INP จากการโต้ตอบของผู้ใช้จริง เราต้องรู้ว่าเครื่องมือรายงานอะไร ก่อนนำตัวเลขต่างชนิดมาเทียบหรือใช้รับงาน

ตามเวลาจากหน้าจอไปถึงงานที่รอ

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

บันทึกไม่ควรมีรหัสผ่าน token หรือข้อมูลลูกค้าที่ไม่จำเป็น แยกรหัสอ้างอิงรายการออกจากรายละเอียดอ่อนไหว และกำหนดสิทธิอ่านกับอายุข้อมูลด้วย การมองเห็นระบบมีต้นทุนของมันเอง ทั้งปริมาณ log ที่จ่ายเงินและความเสี่ยงจากข้อมูลที่เก็บมากเกินไป เรื่องนี้จะกลับมาอยู่ในต้นทุนต่อรายการในตอนที่ 7

ทดสอบให้เกิดงานตามโลกจริง ไม่ให้เครื่องทดสอบช่วยซ่อนคิว

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

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

อย่าให้กราฟรวมลบปัญหาของลูกค้าบางกลุ่ม

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

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

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

คำถามที่ควรถามทีมก่อนจบการประชุม

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

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

อ่านต้นทางและขอบเขตของตัวอย่าง

เอกสารต่อไปนี้เป็นแหล่งอธิบายแนวคิดและข้อจำกัด ตรวจเมื่อ 18 ตุลาคม 2569 ตัวเลขร้านสมมติและข้อเสนอการเลือกทางเป็นการเรียบเรียงของผู้เขียน ไม่ใช่ราคา ผลทดสอบ หรือคำรับรองของแหล่งอ้างอิง ก่อนนำไปตั้งค่าจริงต้องตรวจรุ่น แผน และเงื่อนไขที่ใช้อยู่

• MIT OpenCourseWare: Little’s theorem, lecture 13
• Google web.dev: Web Vitals
• Grafana k6: Open and closed load models
• Google SRE Workbook: Implementing SLOs