Skip to main content



อนิเมะทีวี วิญญาณคร่ำครวญอยากวางมือแล้ว ~วิธีปั้นปาร์ตี้สุดแกร่งโดยฮันเตอร์สุดอ่อน~ (Nageki no Bourei wa Intai Shitai) เผยโปสเตอร์ของช่วงที่ 2

ช่วงที่ 2 เริ่มฉายในเดือนตุลาคม 2025 / 2568




Gobuster คืออะไร? ใช่ขบวนการจารชน โกบัสเตอร์ ป่ะ [evanrintho.buzz]

link.webring.in.th/2607



ฉันรู้สึกว่าหลายๆประเด็นในสังคมมันถดถอย เช่นเรื่อง beauty standard คลั่งขาว แต่งหน้ารองพื้นเบอร์ขาวสุดแล้วบอกโต่วอินบ๊วยเค็ม whitening ตัว ผอมแบบ skinny ใดๆกลับมาเป็นกระแสหลัก เห็นละเศร้า

Mishari Muqbil reshared this.



โศกนาฏกรรมของตัวร้ายสุดแกร่งอย่างราชินีลาสบอสจะขอถวายตัวเพื่อปวงชน (Higeki no Genkyou to Naru Saikyou Gedou Last Boss Joou wa Tami no Tame ni Tsukushimasu.) ยืนยันการผลิตอนิเมะซีซั่น 2

ซีซั่น 1 สามารถรับชมได้ที่ BiliBili, YouTube (Muse Thailand), iQIYI



9to5Linux Weekly Roundup: June 29th, 2025 lxer.com/module/newswire/ext_l…


อนิเมะทีวี ""Omae Gotoki ga Maou ni Kateru to Omou na" to Yuusha Party wo Tsuihou Sareta node, Outo de Kimama ni Kurashitai" เผยภาพทีเซอร์

เริ่มฉายในปี 2026 / 2569



อนิเมะทีวี "Hotel Inhuman โรงแรมเพชฌฆาต" เผยโปสเตอร์ตอน

เริ่มฉายวันที่ 6 กรกฎาคม 2025 / 2568, Crunchyroll สตรีมอนิเมะเรื่องนี้
สตูดิโอโดย Bridge

มังงะวางจำหน่ายในไทยโดย NED Comics



Higeki no Genkyou to Naru Saikyou Gedou Last Boss Joou wa Tami no Tame ni Tsukushimasu. ได้ไปต่อ Season 2

#higekilastboss



จดๆจาก Performance Testing: Analysis Design Develop and Test in Action Workshop รุ่นที่ 1 @SCK DOJO


วันนี้มาเรียนแบบ จ่ายเองนักเลงพอ มาดูว่าที่เค้า Performance Testing มันเป็นยังไงน้า จากทาง SCK Dojo ครับ ที่จดๆมาประมาณนี้ครับ

Table of Contents


Performance Test ทดสอบช่วงไหน ?


เริ่มต้นพี่หนุ่มมาถามก่อนเลยว่า เราควรทำ Performance Test ทดสอบช่วงไหน

แบบต้น Projectวิเคราะห์ และออกแบบระบบcodingหลัง functional testท้ายโครงการ
แบบที่1อย่าหาทำ
แบบที่2ไม่ควรทำ
แบบที่3ไม่ควรทำช่วงท้าย
แบบที่4วิเคราะห์ วางแผน ออกแบบ
เตรียมการสื่อสาร
Perf Test: Test Development
ทดสอบช่วงนี้
Perf Test: Test Exection
ที่มันเหลื่อมๆ กัน เพราต้อง Feedback Sync กลับไปให้ Test Development

ควรทำแบบที่ 4 เพราะ Key สำคัญของ Performance Test อย่างนึง การเห็นภาพรวมทั้งหมด Architecture ของระบบ แล้วมาคุย Flow การไหลของ Request / Event จากนั้นตกลงว่าเทสจุดไหนบ้าง จุดไหนที่ทีมบอกว่าว่ามันตุๆ จะเกิดปัญหา

Performance Test ทำ เพื่ออะไร


❌ เพื่อให้มีของตรวจรับ - ถูกบางส่วน
✅ เพื่อมาทดสอบสมมติฐาน + Cross ตามข้อกำหนด เช่น เรื่อง Auto Scale และหาจุดอ่อน และเสริมให้มันเอาตัวรอดได้ในช่วงเวลาของระบบ

Performance Test ทดสอบแบบเทียบบัญญัติไตรยางค์ตรงๆไม่ได้นะ ปัจจัยมันเยอะ


เรารู้ได้ยังไงว่าเทสจากอะไร ?


📌 มาจาก Need (พวก TOR / RFP) ส่วนใหญ่มันจะคำกลวงๆ ต้องมาเสริม\
📌 Requirement เน้น Non Function List โดยอาจจะสอบถามคนที่เกี่ยวข้องจริง โดยมีคำถาม Guideline และเก็บข้อมูลในรูปแบบของ

  • Non-Funtional Area
  • Requirements + ฺBusiness
  • Current Value ค่าปัจจุบันที่มีย้อนหลังไป ถ้าไม่มี อาจจะต้องมากำหนด Asssumption หรือ ถ้ามีระบบเดิม ต้องไปหามีธีสกัดออกมา อาจจะจาก log
  • Expected Value ณ เวลาใด จะได้จ่ายเงินได้สบายใจ

📌 คำถามที่ควรถาม

  • [Capacity] จำนวนที่หน่วยย่อยที่ใช้งาน Agent / Branch / Account ถ้าบางที่เกี่ยวกับที่ตั้ง อาจจะต้องถามต่ออยู่แถวไหน เช่น SEA
  • [Capacity] Transaction ที่เกิดขึ้นใน 1 ปี
  • [Capacity] ช่วงเวลาที่มีการใช้งานสูงสุด( Peak Time)
  • [Capacity] (Growth rate of transactions in XX Years
  • [Capacity] Num of Users / Growth of Users / Max Concurrent of Users ในเวลาเดียวกัน
  • [Security] ต้องเข้ารหัสอะไรไหม ถ้ามีมันจะช้าลง มันส่งผลกับ Perf
  • [Performance] Response Time by Function/Service ของแต่ละ API
  • [Performance] Workload Type เช่น Online / Batch เวลาที่รับได้แต่ละงานในมุมของ Biz
  • [Availability] Application Service Time เวลาที่ระบบต้องพร้อมใช้งาน จะได้มากำหนดได้ งาน xx ไม่ควรเกิดเวลาไปจากนี้ หรือ ต้องตกลงเพิ่ม
  • [Availability] Maintainace Time (Windows Time)


Test จุดที่ Business บอก Critical
(bool, error) ดังนั้นคนที่เกี่ยวกับ Perf Test เป็นพวก Analyst (BA / SA)


จากคำถามตอนนี้แบบว่าได้คนที่เกี่ยวข้องมาเยอะ และเลย

ใน Perf เรามีกิจกรรมอะไรบ้าง แล้วใครต้องเกี่ยวข้อง


กิจกรรมพวกนี้มันจะล้อไปกับ SDLC จากตอนต้นสรุปไปว่า Perf Test อยู่ช่วงต้น Project > Coding แสดงว่า 8 กิจกรรมของ Performace Testing Core Activities ต้องล้อกันไป

  • Identify Test Environment - Env เทียบเท่า Prod (Production Likely)
  • Identify Acceptance Criterial - ทำ Questionnaire + เก็บ Req สรุปมา เป็น Expected Value
  • Plan and Design Test
  • Prepare Test Environment
  • Record Plan
  • Run Tests
  • Analyst Result ต้องมาดูว่ามันตรง (met) ข้อ 2 ได้ไหม อันที่ไม่ผ่าน เรายอมรับความเสี่ยงได้ไหม แต่ต้องยอมรับบางเคส มีปัญหาต้องวนไปปรับ Code / Arch จะไปวนข้อ 3 ใหม่
  • Tunning & Change Config

ใครต้องเกี่ยวข้อง

  • System Analyst / Solution Architect / Enterprise Architect / Senior Programmer / Infra / Security Team (มาหาข้อตกลง เพราะ ยิ่งเยอะ แล้ว perf ช้าลง) / DBA / QAZ
  • ผู้บริหาร (ที่ชอบรับผิด ชอบ+ ตัดสินใจ) - ตัดสินใจ คุยกับแต่ละฝ่าย แล้วถ้าขึ้นไปแล้ว ถ้ามีปัญหาต้อง Deal กับทุกฝ่าย หาคนนี้ของลูกค้าให้เจอนะ
  • Software Project Manager จะได้เข้าใจ Nature
  • ส่วน Product Owner ขึ้นกับแต่ละทีนะ ถ้าไปลุยจัดการ Req เองก็นับนะ

จากนี้ไปมาแตกย่อยในส่วนของ Performace Testing Core Activities

PT: Identify Test Environment


เกิดขึ้นตอนต้นโครงการ หรือ ก่อนเริ่ม Project

📌 จาก Need (พวก TOR / RFP) ต้องแยกส่วนบอกถึง NFT ในที่นี้จะเป็น performance ออกมา โดยอาจจะเอา Idea จากคำถามข้างต้นมาช่วยกรอง และตอนทำ Requirement ไปขุดสกัดออกมาอีกทีให้ชัดเจน อันนี้ฟังแล้วชอบอันนี้

Ver: 1
- จำนวน Tx ช่วงจันทร์ - ศุกร์ วันละ 50,000 Tx
- จำนวน Tx ช่วงเสาร์ - อาทิตย์ วันละ 90,000 Tx

คาดหวังว่า
Ver: 2 ที่เราทำใหม่ต้องรองรับได้มากกว่าเดิม 4 เท่า

คำว่า 4 เท่าตีความยังไง ?
- Tx ช่วงจันทร์ - ศุกร์ วันละ 50,000 Tx > 200,000 Tx หรือ
- Tx ช่วงจันทร์ - ศุกร์ วันละ 50,000 Tx > 250,000 Tx


📌 จากนั้นต้องตกลง System / Software Archtitecture ให้ได้ก่อน จะได้เห็นว่า

  • ระบบที่เราทำงาน อยู่มีส่วนประกอบอะไรบ้าง รูปแบบการทำงานเป็นอย่างไร ?
  • ระบบรอบข้างที่เกี่ยวข้อง กับเรา รูปแบบการทำงานเป็นอย่างไร ?
  • รูปแบบการทำงานเป็นอย่างไร ? เช่น
    - Online / Batch
    - Request / Response เป็นอย่างไร มี Protocal อย่างไร
    - Sync / Async
    - ปริมาณที่เคยรับได้ + ความสัมพันธ์ >> ตรงนี้ Observability (Log / Trace / Metric) จะช่วยได้เยอะ
  • จากนั้นมาดูได้จุดไหน เป็นจุดอ่อน จุดเสี่ยงได้

📌 พอได้ข้อมูลแล้ว มากำหนด ENV อยากได้แบบ Production - Likely เหมือนที่สุด อาจจะมีการลงทุนด้วย ต้องบวกงบเข้าไปด้วย

📌 ถ้าเราไม่รู้อะไรเลย ข้อมูลเก่าก็ไม่มี

  • อาจจะหาระบบงานที่ใกล้เคียงมา Reference แต่ต้องระวังนะ
  • ถาม user โดยอาจจะทำ Questionnaire หรือ ไปดูข้อมูลจาก Observability System ถ้ามี
  • ถ้ากำหนดมากไป มันจะผลกับ Resource Usage ว่าใช้จริงๆเท่าไหร่ อารมณ์แบบซื้อเครื่องร้อยล้าน แต่ Resource Usage จริงๆใช้ 10% จริงๆ ควรจะใกล้กับ Norm ขององค์กร เช่น กำหนดไว้ว่า 60-70% พวก Cloud / Container / kube เลยมาตอบโจทย์ตรงนี้ เพื่อให้ Resource ใช้คุ้ม


Performance Test ควรใส่ใน Regression Test เพราะได้รู้ว่า Code ไหนเปลี่ยน ทำช้า
ส่วน UI Test อาจจะไม่จำเป็นสำหรับ Regression Test รันเป็นรอบๆ ตามที่ตกลงไว้


📌 อีกคำถามต้องรู้ ผล Performance Test ที่เราทำต้องรองรับได้อีกกี่ปี ใน Condition อะไรบ้าง เช่น ไม่มี Feature เพิ่มหลังจากนี้ มีการทำ Housekeeping xx เป็นต้น

📌 Production-Likely

  • ทั้งในส่วนของ APP และ DB ควรทำให้เหมือนกัน Spec เท่ากันก่อน เขียนถึงที่มา วิธีคิดไว้ชัดเจน ว่าทำมาเพื่อทดสอบสมมติฐานอะไร
  • ถ้า DB แยก Replicate Read / Write ทำเหมือนกัน
  • ถ้าค่อยมาตกลงลด Spec ลงมาตามกำลังทรัพย์


ถ้าหักของออกไป มันจะกระทบอะไรบ้าง และมีความเสี่ยงที่ ยอมรับกันได้ไหม


  • แยก Resource ส่วนที่ Load Injector / System Under Test / Obserability + Monitor คนละชุดกัน


PT: Identify Acceptance Criteria


Acceptance Criteria ข้อตกลงในการตรวจรับ และจ่ายเงินอย่างสบายใจ

จากระบบทำงานได้ถูกต้อง มีอีกหลายส่วนมาเสริม เช่น


- Response Time


📌 วัดการตอบสนองจากระบบ โดยต้องดู 2 มุม Data Point ที่วัดได้ / Average ตัดข้อมูลที่เท่าไหร่ 90% / 95% หรือ 99.5% การเลือกว่าตัดที่เท่าไหร่ ดูว่าจำนวนที่จะมีโอกาศได้เงินจาก Tx สำเร็จนั้นๆ เท่าไหร่ + solution ที่ต้องลงทุนเพิ่ม

📌 ตอนสนองจากไหน

  • Web UI ควรจะไม่เกิน Second - ที่ได้ยินกัน 1-3 Second
  • API ควรจะไม่เกิน Millisecond - Postman จะเอา Default 200ms

📌 กว่าจะตอบมา 1 ทีต้องผ่านอะไรบ้าง ?

Response Time = Latency Time (LT) + Processing Time (PT) ในแต่ละ hop


การจะรู้ว่า Response Time เต็ม มันคิดจากไหนบ้าง เราต้องรู้ Architecture ของระบบ + เส้นทางที่ลูกค้าจะมาถึงระบบเรา เช่น ผ่าน WiFi > Internet > System Under Test

  • มุมคนทั่วไป - ตั้งแต่กด Enter สั่งจนเว็บ Render เสร็จ
  • มุม Perf Tools - บิตแรกถูกส่งไป และตัดสุดท้ายที่ได้รับ

📌 เครื่องมือ Tools ที่ Test Performance ควรมี Probe ด้วย อย่าง load runner มี probe

probe = เครื่องมือจับที่ละ hop ผ่าน Web - App - DB หรือ External System เป็นต้น ถ้าในยุคนี้จะเป็นพวก Tracing ของ Observability (แอบดีใจ App ที่ไปช่วยล่าสุดมีเน้นเรื่องนี้ไป ตอนแก้ Perf ดู Trace ง่ายมาก)

- Success Rate / Fail Rate


📌 ถ้าเป็น web จะเป็นพวก http code อย่าง 2xx ควรจะ 100% และมีพวก 4xx หรือ 5xx ให้น้อยที่สุด

📌 ถ้ามีมาแสดงว่า มันต้องร่วงสักจุดในระบบ

- Resource Utilization


📌ดูที่ไหนบ้าง > ทุกจุด ทั้ง App / DB และตัว Host ที่มันรันอยู่ด้วย เรียกว่าเป็นการบูรณาการข้อมูลจาก Infra / App / DB เห็นหลายอันพยายามออกข้อมูลในรูปแบบของ Open Telemetry ด้วย เพราะตัว Perf Tools มันเก็บได้ไม่หมด อยากกมากได้แค่ตัว CPU / Memory

📌 ดูอะไรบ้าง มีหลายส่วน ตามนี้เลย

RESOUREค่าที่คุ้มค่าที่ต้อง Alert
CPU / Memory / Disk / Bandwidth / Queue เป็นต้นคุ้มกับเงินที่ลงทุนไป เช่น อยากให้ซื่อ Server แล้ว CPU ใน load ปกติใช้งานประมาณ 55-60% ถ้าเกินต้องส่งคนเข้าไปดู ก่อนระบบดับ เข่น 75% นานเกิน 1 ชั่วโมง เป็นตน

📌 นอกจากดู Resource อาจจะวัดจาก SLA ความพร้อมใช้งานระบบ เช่น ตามช่วงเวลาทำงาน

📌 อีกประเด็นมี Request Simulate มาเท่าไหร่ ?

PT: Plan and Design Test


📌 เข้าใจกันก่อน ถึงรูปแบบของ Virtual Users (VUs) เป็นอย่างไร และ Workload Model อย่างไร Workload Model มี 3 ส่วน ได้แก่

  • Ramp-Up
  • Steady
  • Ramp-Down

📌 ข้อมูล Workload มาจากไหน

  • ข้อมูลในอดีต
    - อาจจะเอาจาก Log ของระบบเดิม ทีม Infra มา Visualize ว่ามันมี Wave ของ Workload อย่างไร
    - Query จาก Log เดิมของระบบ
    - หรือ ถ้าไม่มีต้องสอบถาม และไปเทียบเคียงกับระบบที่คล้ายๆกัน
  • พอได้ข้อมูลแล้ว เราต้องมาแบ่งในแค่ละช่วงเวลา Workload มาเป็นอย่างไร และจุดไหนควรทดสอบ จุดไหนไม่ควรทดสอบ

📌 จากนั้นมา Simulated Load ตัว Workload โดยดูจาก

  • ตาม Step การใช้งานจริงตาม Business Steps / End User Business Flow / Customer Journey
  • มี think time behavior (ช่วงเวลา แต่ละ action หยุดคิดของผู้ใช้ หยุดคิด มันยึด resource) เช่น คิดเลือกสิ้นค้าจากตะก้รา หรือ เพิ่มลดวิชา
  • ระบบมี caching ไหมถ้ามี ต้องคิดเคสที่ TTL หมดอายุด้วยนะ หรือ ตาย พฤติกรรมเปลี่ยนไปอย่างไร
  • geographical distribution ใช้จากที่ไหน browser / device อะไร

📌 รูปแบบของ Workload

  • Load Test - ทดสอบตาม Max Design Capacity
    - มี Ramp-up / Steady / Ramp-Down อันเดียว ทดสอบ 1 API
  • Flow Test (Load Test Multi-Steps Ramp-up)
    - ทดสอบตาม Flow Business ยิง API 1 ต่อด้วย API 2 3 .. จนครบ Flow Business จะได้ Workload Model ซ้อนกันไปเรื่อยๆ
  • Endurance Test - เทสความทนทาน ทดสอบ Durability จะช่วยเรื่อง
    - เคสแบบ App Run เช้าเร็ว บ่ายช้า เลยต้อง Restart นานๆเข้า เช้าเร็ว สัก 10 โมงเริ่มช้าแล้ว ถ้า java เคส GC มัน Clear ของเดิมไม่ทัน GC ส่งงานใหม่มารอ
    - ทดสอบ Response Time ว่าช้าลงไหม / Resource Utilization มันควรจะ Stable ถ้าเปิดเฉยๆ แล้วตัว memory leak ต้องมาดูแล้วว่าหลุดที่ไหน
  • Stress Tests
    - มาหาจุด Break Point ไม่ใช่หาจุดคอขวด และวางแผน + ทำ Code / Microservice ที่เกิดปัญหา
    - อยากรู้ว่า เรารองรับได้ไปอีกกี่ปี ตามสัดส่วนการ Growth ตาม Business ปี 1 2 3 …
    - ส่วน Load Test ทดสอบตาม Max Design Capacity
  • Spike Test - ทดสอบว่าระบบรองรับไหม ถ้าอยู่มี Traffic เพิ่มขึ้นมาจาก Load Test แปบๆ อาจจะมี 1 Spike หรือ หลาย Spike ก็ได้ ต้องมาดูว่าช่วย Spike มีอะไรที่สะดุดไหม ตัวอย่าง วันหวยออก / ระบบลงทะเบียน มันจะ Spike ช่วงแรก พอคนทำงานเสร็จ Traffic ลดลงไปเป็นปกติ
  • Scalability Test เอาไว้ดูว่าถ้าถึงเงื่อนไขที่ระบบต้อง Scale แล้ว ระบบ Scale จริงไหม นึกถึงภาพตัวเองเปิด Cloud Shell แล้วยิง App Service / EKS ดูว่ามันสร้าง Instance ขึ้นมาตามไหม
  • Volume Test เอา Data Dump ลง Database แล้วดูการตอบสนองจากส่วนอื่นๆของระบบ


💡ส่วน Chaos Test มันจะคนละมุมกับ Performance Test ตัว Chaos Test มันเป็นสิ่งที่เราคุมไม่ได้นะ


PT: Prepare Test Environment (🏗️ Arrange 🏗️) +
PT: Record Plan


📌 เตรียม Production-Likely Resource

  • ส่วนที่ Load Injector / System Under Test / Obserability + Monitor คนละชุดกัน
  • เริ่มต้นอาจจะทำมือ
  • แต่ถ้าต้องสร้างลบบ่อยๆ พบ Script เข้ามาช่วย
    - Docker / Docker Compose
    - Scale มาหน่อย K8S หรือ Cloud ของแต่ละค่าย
  • ตกลงกับ Network Infra ให้เรียบร้อย ว่าจะยิงน้า จะได้ไม่โดน Firewall Filter ทิ้ง หรือ ถ้าแยก Env ไว้ อาจจะของเค้าช่วย Duplicate Traffic มาใส่ได้ได้

📌 เตรียม Test Data ตามปริมาณข้อมูล

  • ใช้ Tools Generate Data ใน Class จะเป็นตัว fakerjs.dev/
  • ให้ Dev API ช่วย Dump ที่ผมเคยทำนะ

📌 เตรียม External Service

  • อาจจะทำ Stub / Mock API มาใช้งาน ถ้าไม่มีให้ลอง

📌 เตรียม Performance Testing Tools

  • เลือกใช้ Tools อะไรเอาตัวนั้นเลย เพราะแต่ละตัวมีวิธีวัด ไม่เหมือนกัน จะเอาผล Tools A มาชนกับ B ไม่ได้
  • Tools มีหลายตัว
    - Grafrana K6 (OSS / Cloud-Commercial) เขียน JS + CLI
    - JMeter (OSS)
    - wrk (OSS)
    - LoadRunner (Commercial)
    - vegeta (OSS)
    - bombardier (OSS)

📌 เขียน Performance Testing Script ตามที่ Design ไว้ สำหรับใน Class พี่ปุ๋ย พี่บอม ลองเน้น 2 ตัว Grafrana K6 / JMeter

  • Grafrana K6 - เป็น Script เขียนด้วย JS ใช้ AI มัน Gen ออกมาพออ่านได้ นอกจากนี้ตัวแปลงจาก postman collector postman-to-k6 ลองเขียน script ตามนี้


import http from 'k6/http';import { sleep } from 'k6';export const options = { // Key configurations for Stress in this section // แบบเดิม // stages: [ // { duration: '30s', target: 10 }, // traffic ramp-up from 1 to a higher 10 users over 5 seconds. // { duration: '120s', target: 10 }, // stay at higher 10 users for 30 seconds // { duration: '30s', target: 0 }, // ramp-down to 0 users // ], tags:{ type: "load-test", name: 'product-get-test', testid: 'lab1-1', }, // แบบใหม่ เอามาแทน stages //https://grafana.com/docs/k6/latest/using-k6/scenarios/ scenarios: { get_product_information: { //https://grafana.com/docs/k6/latest/using-k6/scenarios/executors/constant-vus/ //https://grafana.com/docs/k6/latest/using-k6/scenarios/executors/ramping-vus/ executor: 'constant-vus', //constant-vus ขึ้นเลย ramping-vus ค่อยๆ ขึ้น vus: 10, // 10 virtual users duration: '180s', // run for 180 seconds gracefulStop: '5s', // allow 5 seconds for graceful shutdown }, },};export default () => { const urlRes = http.get('https://quickpizza.grafana.com/'); // Thnik time between request ตอนลองจริงต้องมีหลาย Scenario sleep(Math.random() * 2 + 1); //check the response status check(urlRes, { 'status is 200': (r) => r.status === 200, 'status is not 400': (r) => r.status !== 400, 'status is not 500': (r) => r.status !== 500, 'response time < 200ms': (r) => r.timings.duration < 200, });};

มี Version GUI ด้วยนะ github.com/grafana/k6-studio


  • JMeter ตอนแรก พวกได้ Workload Model ให้ AI มัน Gen ให้ ไม่รู้เรื่องเลย 5555 พอมากด UI เข้าใจและ
  • wrk ใช้สำหรับลองง่ายๆ ก่อนดู Cap เบื้องต้น ถ้าทำมากกว่านั้นภาษา lua เขียน

นอกจากนี้ ถ้าใครใช้ Postman มันมีตัว Perf Test จะ แต่อาจจะติด Limit Concurrent การยิง ต้องเสียเงินเพิ่ม กลับกัน K6 เหมือนออกตัว Studio มาด้วย อาจจะเข้ามาทำแบบ Post

ตอนแรกเขียน 2 ทำไมงอก 555


📌 Collect Result ยังไง เครื่องตัวเอง หรือ หลายเครื่องยิงเอง ตรงนี้พี่ปุ๋ย พี่บอม มีพา Demo

  • เอา Local Report จาก K6 / JMeter
  • รวมถึงเอาผลมาทำเป็น Centralize จะได้เก็บที่เดียว และดูภาพรวมได้ทั้งหมด ใช้ตัว LGTM Stack อย่างตัว
    - Prometheous/Mimir - เก็บ Time Series ที่ได้จากการ Test แต่ตัว JMeter ไปทาง InfluxDB จะดีกว่า เพราะ JMeter ทดของไว้ในนั้นตอนรัน
    - Grafrana มาแสดงผล
    - Sample ของพี่ปุ้ย github.com/up1/workshop-perfor…


สุดท้ายอย่าลืมเก็บของลงใน Source Control ด้วย เป็นไปได้ควรอยู่ที่เดียวกับ Dev


PT: Run Tests (🤺ACT / ASSERT🤺)


  • ถ้าพร้อมแล้วก็ลุยทดสอบตาม Workload Model ที่เลือกไว้ เช่น เจอ load เยอะ ช่วย 11pm เมื่อวาน - ตี 2 วันถัดไป และอีกช่วง 9 โมงถึงบ่าย 2 รันทิ้งไว้ตามเวลานั้นๆเลยครับ
  • การ Run Test ให้ใช้แบบ CLI ถ้ากดจาก GUI ตัว UI อาจจะเดี้ยงก่อน
  • Load Injector แยก server หรือ ใช้ตัวเล็กๆ หลายตัว มาแบ่งๆ แต่คุยกับ network จะได้ไม่โดย Filter ออกไป และก็การสร้าง Virtual User มันใช้ Mem Tools มันใช้ Mem ถ้าเครื่องยิงไม่แรงพอ คนยิงตายเองก่อน
  • พวก load balance / api gw เป็นไปได้ ควรตัดออกไปก่อน จะได้รู้ว่า App มันรับได้จริงๆ เท่าไหร่ อาจจะโดนกันไป


PT: Analyst Result


เอาผลลัพธ์จาก Test Report มาดู เข้า Request Sucess / Fail หรือ รวมถึงดูจากข้อมูลที่ Percentile ที่เท่าไหร่
K6Jmeter
นอกจากนี้แล้วในช่วงเวลาเดียวกัน เราสามารถไปดูจากส่วน Observability System ได้ ว่าช่วยเวลาที่มีปัญหาจาก Perf Test Trace เวลาเดียวกัน Trace มันไปตายในจุดไหน เช่น App ตาย ส่วน DB เหงาไม่มีใครมา Query เป็นต้น
Grafana Prometheus StackFilter By TestId

PT: Tunning & Change Config


อันนี้ใน Class ไม่ได้สอน ผมเข้าใจว่า ถ้า Analyst Result ได้ แล้วไปดู Log Trace ว่าช้าตรงไหนเจอ เราไปแก้ Code หรือ Config ได้ ครับ

สำหรับ Class นี้จะเน้นสอนการคิดนะ เข้าใจส่วน Tools มาเสริมการใช้งานเบื้องต้นครับ เข้าใจมากขึ้นเยอะ ว่าที่เค้า Report มาให้ปรับๆ มันเป็นยังไง ขอบคุณทีมงานมากๆครับ


Reference


#performance #Observability #PerfTest



จดๆจาก Performance Testing: Analysis Design Develop and Test in Action Workshop รุ่นที่ 1 @SCK DOJO

วันนี้มาเรียนแบบ จ่ายเองนักเลงพอ มาดูว่าที่เค้า Performance Testing มันเป็นยังไงน้า จากทาง SCK Dojo ครับ ที่จดๆมาประมาณนี้ครับ Performance Test ทดสอบช่วงไหน ? Performance Test ทำ เพื่ออะไร เรารู้ได้ยังไงว่าเทสจากอะไร ? ใน Perf เรามีกิจกรรมอะไรบ้าง แล้วใครต้องเกี่ยวข้อง PT: Identify Test Environment PT: Identify Acceptance Criteria - Response Time - Success Rate / Fail…

naiwaen.debuggingsoft.com/2025…


จดๆจาก Performance Testing: Analysis Design Develop and Test in Action Workshop รุ่นที่ 1 @SCK DOJO


วันนี้มาเรียนแบบ จ่ายเองนักเลงพอ มาดูว่าที่เค้า Performance Testing มันเป็นยังไงน้า จากทาง SCK Dojo ครับ ที่จดๆมาประมาณนี้ครับ

Table of Contents


Performance Test ทดสอบช่วงไหน ?


เริ่มต้นพี่หนุ่มมาถามก่อนเลยว่า เราควรทำ Performance Test ทดสอบช่วงไหน

แบบต้น Projectวิเคราะห์ และออกแบบระบบcodingหลัง functional testท้ายโครงการ
แบบที่1อย่าหาทำ
แบบที่2ไม่ควรทำ
แบบที่3ไม่ควรทำช่วงท้าย
แบบที่4วิเคราะห์ วางแผน ออกแบบ
เตรียมการสื่อสาร
Perf Test: Test Development
ทดสอบช่วงนี้
Perf Test: Test Exection
ที่มันเหลื่อมๆ กัน เพราต้อง Feedback Sync กลับไปให้ Test Development

ควรทำแบบที่ 4 เพราะ Key สำคัญของ Performance Test อย่างนึง การเห็นภาพรวมทั้งหมด Architecture ของระบบ แล้วมาคุย Flow การไหลของ Request / Event จากนั้นตกลงว่าเทสจุดไหนบ้าง จุดไหนที่ทีมบอกว่าว่ามันตุๆ จะเกิดปัญหา

Performance Test ทำ เพื่ออะไร


❌ เพื่อให้มีของตรวจรับ - ถูกบางส่วน
✅ เพื่อมาทดสอบสมมติฐาน + Cross ตามข้อกำหนด เช่น เรื่อง Auto Scale และหาจุดอ่อน และเสริมให้มันเอาตัวรอดได้ในช่วงเวลาของระบบ

Performance Test ทดสอบแบบเทียบบัญญัติไตรยางค์ตรงๆไม่ได้นะ ปัจจัยมันเยอะ


เรารู้ได้ยังไงว่าเทสจากอะไร ?


📌 มาจาก Need (พวก TOR / RFP) ส่วนใหญ่มันจะคำกลวงๆ ต้องมาเสริม\
📌 Requirement เน้น Non Function List โดยอาจจะสอบถามคนที่เกี่ยวข้องจริง โดยมีคำถาม Guideline และเก็บข้อมูลในรูปแบบของ

  • Non-Funtional Area
  • Requirements + ฺBusiness
  • Current Value ค่าปัจจุบันที่มีย้อนหลังไป ถ้าไม่มี อาจจะต้องมากำหนด Asssumption หรือ ถ้ามีระบบเดิม ต้องไปหามีธีสกัดออกมา อาจจะจาก log
  • Expected Value ณ เวลาใด จะได้จ่ายเงินได้สบายใจ

📌 คำถามที่ควรถาม

  • [Capacity] จำนวนที่หน่วยย่อยที่ใช้งาน Agent / Branch / Account ถ้าบางที่เกี่ยวกับที่ตั้ง อาจจะต้องถามต่ออยู่แถวไหน เช่น SEA
  • [Capacity] Transaction ที่เกิดขึ้นใน 1 ปี
  • [Capacity] ช่วงเวลาที่มีการใช้งานสูงสุด( Peak Time)
  • [Capacity] (Growth rate of transactions in XX Years
  • [Capacity] Num of Users / Growth of Users / Max Concurrent of Users ในเวลาเดียวกัน
  • [Security] ต้องเข้ารหัสอะไรไหม ถ้ามีมันจะช้าลง มันส่งผลกับ Perf
  • [Performance] Response Time by Function/Service ของแต่ละ API
  • [Performance] Workload Type เช่น Online / Batch เวลาที่รับได้แต่ละงานในมุมของ Biz
  • [Availability] Application Service Time เวลาที่ระบบต้องพร้อมใช้งาน จะได้มากำหนดได้ งาน xx ไม่ควรเกิดเวลาไปจากนี้ หรือ ต้องตกลงเพิ่ม
  • [Availability] Maintainace Time (Windows Time)


Test จุดที่ Business บอก Critical
(bool, error) ดังนั้นคนที่เกี่ยวกับ Perf Test เป็นพวก Analyst (BA / SA)


จากคำถามตอนนี้แบบว่าได้คนที่เกี่ยวข้องมาเยอะ และเลย

ใน Perf เรามีกิจกรรมอะไรบ้าง แล้วใครต้องเกี่ยวข้อง


กิจกรรมพวกนี้มันจะล้อไปกับ SDLC จากตอนต้นสรุปไปว่า Perf Test อยู่ช่วงต้น Project > Coding แสดงว่า 8 กิจกรรมของ Performace Testing Core Activities ต้องล้อกันไป

  • Identify Test Environment - Env เทียบเท่า Prod (Production Likely)
  • Identify Acceptance Criterial - ทำ Questionnaire + เก็บ Req สรุปมา เป็น Expected Value
  • Plan and Design Test
  • Prepare Test Environment
  • Record Plan
  • Run Tests
  • Analyst Result ต้องมาดูว่ามันตรง (met) ข้อ 2 ได้ไหม อันที่ไม่ผ่าน เรายอมรับความเสี่ยงได้ไหม แต่ต้องยอมรับบางเคส มีปัญหาต้องวนไปปรับ Code / Arch จะไปวนข้อ 3 ใหม่
  • Tunning & Change Config

ใครต้องเกี่ยวข้อง

  • System Analyst / Solution Architect / Enterprise Architect / Senior Programmer / Infra / Security Team (มาหาข้อตกลง เพราะ ยิ่งเยอะ แล้ว perf ช้าลง) / DBA / QAZ
  • ผู้บริหาร (ที่ชอบรับผิด ชอบ+ ตัดสินใจ) - ตัดสินใจ คุยกับแต่ละฝ่าย แล้วถ้าขึ้นไปแล้ว ถ้ามีปัญหาต้อง Deal กับทุกฝ่าย หาคนนี้ของลูกค้าให้เจอนะ
  • Software Project Manager จะได้เข้าใจ Nature
  • ส่วน Product Owner ขึ้นกับแต่ละทีนะ ถ้าไปลุยจัดการ Req เองก็นับนะ

จากนี้ไปมาแตกย่อยในส่วนของ Performace Testing Core Activities

PT: Identify Test Environment


เกิดขึ้นตอนต้นโครงการ หรือ ก่อนเริ่ม Project

📌 จาก Need (พวก TOR / RFP) ต้องแยกส่วนบอกถึง NFT ในที่นี้จะเป็น performance ออกมา โดยอาจจะเอา Idea จากคำถามข้างต้นมาช่วยกรอง และตอนทำ Requirement ไปขุดสกัดออกมาอีกทีให้ชัดเจน อันนี้ฟังแล้วชอบอันนี้

Ver: 1
- จำนวน Tx ช่วงจันทร์ - ศุกร์ วันละ 50,000 Tx
- จำนวน Tx ช่วงเสาร์ - อาทิตย์ วันละ 90,000 Tx

คาดหวังว่า
Ver: 2 ที่เราทำใหม่ต้องรองรับได้มากกว่าเดิม 4 เท่า

คำว่า 4 เท่าตีความยังไง ?
- Tx ช่วงจันทร์ - ศุกร์ วันละ 50,000 Tx > 200,000 Tx หรือ
- Tx ช่วงจันทร์ - ศุกร์ วันละ 50,000 Tx > 250,000 Tx


📌 จากนั้นต้องตกลง System / Software Archtitecture ให้ได้ก่อน จะได้เห็นว่า

  • ระบบที่เราทำงาน อยู่มีส่วนประกอบอะไรบ้าง รูปแบบการทำงานเป็นอย่างไร ?
  • ระบบรอบข้างที่เกี่ยวข้อง กับเรา รูปแบบการทำงานเป็นอย่างไร ?
  • รูปแบบการทำงานเป็นอย่างไร ? เช่น
    - Online / Batch
    - Request / Response เป็นอย่างไร มี Protocal อย่างไร
    - Sync / Async
    - ปริมาณที่เคยรับได้ + ความสัมพันธ์ >> ตรงนี้ Observability (Log / Trace / Metric) จะช่วยได้เยอะ
  • จากนั้นมาดูได้จุดไหน เป็นจุดอ่อน จุดเสี่ยงได้

📌 พอได้ข้อมูลแล้ว มากำหนด ENV อยากได้แบบ Production - Likely เหมือนที่สุด อาจจะมีการลงทุนด้วย ต้องบวกงบเข้าไปด้วย

📌 ถ้าเราไม่รู้อะไรเลย ข้อมูลเก่าก็ไม่มี

  • อาจจะหาระบบงานที่ใกล้เคียงมา Reference แต่ต้องระวังนะ
  • ถาม user โดยอาจจะทำ Questionnaire หรือ ไปดูข้อมูลจาก Observability System ถ้ามี
  • ถ้ากำหนดมากไป มันจะผลกับ Resource Usage ว่าใช้จริงๆเท่าไหร่ อารมณ์แบบซื้อเครื่องร้อยล้าน แต่ Resource Usage จริงๆใช้ 10% จริงๆ ควรจะใกล้กับ Norm ขององค์กร เช่น กำหนดไว้ว่า 60-70% พวก Cloud / Container / kube เลยมาตอบโจทย์ตรงนี้ เพื่อให้ Resource ใช้คุ้ม


Performance Test ควรใส่ใน Regression Test เพราะได้รู้ว่า Code ไหนเปลี่ยน ทำช้า
ส่วน UI Test อาจจะไม่จำเป็นสำหรับ Regression Test รันเป็นรอบๆ ตามที่ตกลงไว้


📌 อีกคำถามต้องรู้ ผล Performance Test ที่เราทำต้องรองรับได้อีกกี่ปี ใน Condition อะไรบ้าง เช่น ไม่มี Feature เพิ่มหลังจากนี้ มีการทำ Housekeeping xx เป็นต้น

📌 Production-Likely

  • ทั้งในส่วนของ APP และ DB ควรทำให้เหมือนกัน Spec เท่ากันก่อน เขียนถึงที่มา วิธีคิดไว้ชัดเจน ว่าทำมาเพื่อทดสอบสมมติฐานอะไร
  • ถ้า DB แยก Replicate Read / Write ทำเหมือนกัน
  • ถ้าค่อยมาตกลงลด Spec ลงมาตามกำลังทรัพย์


ถ้าหักของออกไป มันจะกระทบอะไรบ้าง และมีความเสี่ยงที่ ยอมรับกันได้ไหม


  • แยก Resource ส่วนที่ Load Injector / System Under Test / Obserability + Monitor คนละชุดกัน


PT: Identify Acceptance Criteria


Acceptance Criteria ข้อตกลงในการตรวจรับ และจ่ายเงินอย่างสบายใจ

จากระบบทำงานได้ถูกต้อง มีอีกหลายส่วนมาเสริม เช่น


- Response Time


📌 วัดการตอบสนองจากระบบ โดยต้องดู 2 มุม Data Point ที่วัดได้ / Average ตัดข้อมูลที่เท่าไหร่ 90% / 95% หรือ 99.5% การเลือกว่าตัดที่เท่าไหร่ ดูว่าจำนวนที่จะมีโอกาศได้เงินจาก Tx สำเร็จนั้นๆ เท่าไหร่ + solution ที่ต้องลงทุนเพิ่ม

📌 ตอนสนองจากไหน

  • Web UI ควรจะไม่เกิน Second - ที่ได้ยินกัน 1-3 Second
  • API ควรจะไม่เกิน Millisecond - Postman จะเอา Default 200ms

📌 กว่าจะตอบมา 1 ทีต้องผ่านอะไรบ้าง ?

Response Time = Latency Time (LT) + Processing Time (PT) ในแต่ละ hop


การจะรู้ว่า Response Time เต็ม มันคิดจากไหนบ้าง เราต้องรู้ Architecture ของระบบ + เส้นทางที่ลูกค้าจะมาถึงระบบเรา เช่น ผ่าน WiFi > Internet > System Under Test

  • มุมคนทั่วไป - ตั้งแต่กด Enter สั่งจนเว็บ Render เสร็จ
  • มุม Perf Tools - บิตแรกถูกส่งไป และตัดสุดท้ายที่ได้รับ

📌 เครื่องมือ Tools ที่ Test Performance ควรมี Probe ด้วย อย่าง load runner มี probe

probe = เครื่องมือจับที่ละ hop ผ่าน Web - App - DB หรือ External System เป็นต้น ถ้าในยุคนี้จะเป็นพวก Tracing ของ Observability (แอบดีใจ App ที่ไปช่วยล่าสุดมีเน้นเรื่องนี้ไป ตอนแก้ Perf ดู Trace ง่ายมาก)

- Success Rate / Fail Rate


📌 ถ้าเป็น web จะเป็นพวก http code อย่าง 2xx ควรจะ 100% และมีพวก 4xx หรือ 5xx ให้น้อยที่สุด

📌 ถ้ามีมาแสดงว่า มันต้องร่วงสักจุดในระบบ

- Resource Utilization


📌ดูที่ไหนบ้าง > ทุกจุด ทั้ง App / DB และตัว Host ที่มันรันอยู่ด้วย เรียกว่าเป็นการบูรณาการข้อมูลจาก Infra / App / DB เห็นหลายอันพยายามออกข้อมูลในรูปแบบของ Open Telemetry ด้วย เพราะตัว Perf Tools มันเก็บได้ไม่หมด อยากกมากได้แค่ตัว CPU / Memory

📌 ดูอะไรบ้าง มีหลายส่วน ตามนี้เลย

RESOUREค่าที่คุ้มค่าที่ต้อง Alert
CPU / Memory / Disk / Bandwidth / Queue เป็นต้นคุ้มกับเงินที่ลงทุนไป เช่น อยากให้ซื่อ Server แล้ว CPU ใน load ปกติใช้งานประมาณ 55-60% ถ้าเกินต้องส่งคนเข้าไปดู ก่อนระบบดับ เข่น 75% นานเกิน 1 ชั่วโมง เป็นตน

📌 นอกจากดู Resource อาจจะวัดจาก SLA ความพร้อมใช้งานระบบ เช่น ตามช่วงเวลาทำงาน

📌 อีกประเด็นมี Request Simulate มาเท่าไหร่ ?

PT: Plan and Design Test


📌 เข้าใจกันก่อน ถึงรูปแบบของ Virtual Users (VUs) เป็นอย่างไร และ Workload Model อย่างไร Workload Model มี 3 ส่วน ได้แก่

  • Ramp-Up
  • Steady
  • Ramp-Down

📌 ข้อมูล Workload มาจากไหน

  • ข้อมูลในอดีต
    - อาจจะเอาจาก Log ของระบบเดิม ทีม Infra มา Visualize ว่ามันมี Wave ของ Workload อย่างไร
    - Query จาก Log เดิมของระบบ
    - หรือ ถ้าไม่มีต้องสอบถาม และไปเทียบเคียงกับระบบที่คล้ายๆกัน
  • พอได้ข้อมูลแล้ว เราต้องมาแบ่งในแค่ละช่วงเวลา Workload มาเป็นอย่างไร และจุดไหนควรทดสอบ จุดไหนไม่ควรทดสอบ

📌 จากนั้นมา Simulated Load ตัว Workload โดยดูจาก

  • ตาม Step การใช้งานจริงตาม Business Steps / End User Business Flow / Customer Journey
  • มี think time behavior (ช่วงเวลา แต่ละ action หยุดคิดของผู้ใช้ หยุดคิด มันยึด resource) เช่น คิดเลือกสิ้นค้าจากตะก้รา หรือ เพิ่มลดวิชา
  • ระบบมี caching ไหมถ้ามี ต้องคิดเคสที่ TTL หมดอายุด้วยนะ หรือ ตาย พฤติกรรมเปลี่ยนไปอย่างไร
  • geographical distribution ใช้จากที่ไหน browser / device อะไร

📌 รูปแบบของ Workload

  • Load Test - ทดสอบตาม Max Design Capacity
    - มี Ramp-up / Steady / Ramp-Down อันเดียว ทดสอบ 1 API
  • Flow Test (Load Test Multi-Steps Ramp-up)
    - ทดสอบตาม Flow Business ยิง API 1 ต่อด้วย API 2 3 .. จนครบ Flow Business จะได้ Workload Model ซ้อนกันไปเรื่อยๆ
  • Endurance Test - เทสความทนทาน ทดสอบ Durability จะช่วยเรื่อง
    - เคสแบบ App Run เช้าเร็ว บ่ายช้า เลยต้อง Restart นานๆเข้า เช้าเร็ว สัก 10 โมงเริ่มช้าแล้ว ถ้า java เคส GC มัน Clear ของเดิมไม่ทัน GC ส่งงานใหม่มารอ
    - ทดสอบ Response Time ว่าช้าลงไหม / Resource Utilization มันควรจะ Stable ถ้าเปิดเฉยๆ แล้วตัว memory leak ต้องมาดูแล้วว่าหลุดที่ไหน
  • Stress Tests
    - มาหาจุด Break Point ไม่ใช่หาจุดคอขวด และวางแผน + ทำ Code / Microservice ที่เกิดปัญหา
    - อยากรู้ว่า เรารองรับได้ไปอีกกี่ปี ตามสัดส่วนการ Growth ตาม Business ปี 1 2 3 …
    - ส่วน Load Test ทดสอบตาม Max Design Capacity
  • Spike Test - ทดสอบว่าระบบรองรับไหม ถ้าอยู่มี Traffic เพิ่มขึ้นมาจาก Load Test แปบๆ อาจจะมี 1 Spike หรือ หลาย Spike ก็ได้ ต้องมาดูว่าช่วย Spike มีอะไรที่สะดุดไหม ตัวอย่าง วันหวยออก / ระบบลงทะเบียน มันจะ Spike ช่วงแรก พอคนทำงานเสร็จ Traffic ลดลงไปเป็นปกติ
  • Scalability Test เอาไว้ดูว่าถ้าถึงเงื่อนไขที่ระบบต้อง Scale แล้ว ระบบ Scale จริงไหม นึกถึงภาพตัวเองเปิด Cloud Shell แล้วยิง App Service / EKS ดูว่ามันสร้าง Instance ขึ้นมาตามไหม
  • Volume Test เอา Data Dump ลง Database แล้วดูการตอบสนองจากส่วนอื่นๆของระบบ


💡ส่วน Chaos Test มันจะคนละมุมกับ Performance Test ตัว Chaos Test มันเป็นสิ่งที่เราคุมไม่ได้นะ


PT: Prepare Test Environment (🏗️ Arrange 🏗️) +
PT: Record Plan


📌 เตรียม Production-Likely Resource

  • ส่วนที่ Load Injector / System Under Test / Obserability + Monitor คนละชุดกัน
  • เริ่มต้นอาจจะทำมือ
  • แต่ถ้าต้องสร้างลบบ่อยๆ พบ Script เข้ามาช่วย
    - Docker / Docker Compose
    - Scale มาหน่อย K8S หรือ Cloud ของแต่ละค่าย
  • ตกลงกับ Network Infra ให้เรียบร้อย ว่าจะยิงน้า จะได้ไม่โดน Firewall Filter ทิ้ง หรือ ถ้าแยก Env ไว้ อาจจะของเค้าช่วย Duplicate Traffic มาใส่ได้ได้

📌 เตรียม Test Data ตามปริมาณข้อมูล

  • ใช้ Tools Generate Data ใน Class จะเป็นตัว fakerjs.dev/
  • ให้ Dev API ช่วย Dump ที่ผมเคยทำนะ

📌 เตรียม External Service

  • อาจจะทำ Stub / Mock API มาใช้งาน ถ้าไม่มีให้ลอง

📌 เตรียม Performance Testing Tools

  • เลือกใช้ Tools อะไรเอาตัวนั้นเลย เพราะแต่ละตัวมีวิธีวัด ไม่เหมือนกัน จะเอาผล Tools A มาชนกับ B ไม่ได้
  • Tools มีหลายตัว
    - Grafrana K6 (OSS / Cloud-Commercial) เขียน JS + CLI
    - JMeter (OSS)
    - wrk (OSS)
    - LoadRunner (Commercial)
    - vegeta (OSS)
    - bombardier (OSS)

📌 เขียน Performance Testing Script ตามที่ Design ไว้ สำหรับใน Class พี่ปุ๋ย พี่บอม ลองเน้น 2 ตัว Grafrana K6 / JMeter

  • Grafrana K6 - เป็น Script เขียนด้วย JS ใช้ AI มัน Gen ออกมาพออ่านได้ นอกจากนี้ตัวแปลงจาก postman collector postman-to-k6 ลองเขียน script ตามนี้


import http from 'k6/http';import { sleep } from 'k6';export const options = { // Key configurations for Stress in this section // แบบเดิม // stages: [ // { duration: '30s', target: 10 }, // traffic ramp-up from 1 to a higher 10 users over 5 seconds. // { duration: '120s', target: 10 }, // stay at higher 10 users for 30 seconds // { duration: '30s', target: 0 }, // ramp-down to 0 users // ], tags:{ type: "load-test", name: 'product-get-test', testid: 'lab1-1', }, // แบบใหม่ เอามาแทน stages //https://grafana.com/docs/k6/latest/using-k6/scenarios/ scenarios: { get_product_information: { //https://grafana.com/docs/k6/latest/using-k6/scenarios/executors/constant-vus/ //https://grafana.com/docs/k6/latest/using-k6/scenarios/executors/ramping-vus/ executor: 'constant-vus', //constant-vus ขึ้นเลย ramping-vus ค่อยๆ ขึ้น vus: 10, // 10 virtual users duration: '180s', // run for 180 seconds gracefulStop: '5s', // allow 5 seconds for graceful shutdown }, },};export default () => { const urlRes = http.get('https://quickpizza.grafana.com/'); // Thnik time between request ตอนลองจริงต้องมีหลาย Scenario sleep(Math.random() * 2 + 1); //check the response status check(urlRes, { 'status is 200': (r) => r.status === 200, 'status is not 400': (r) => r.status !== 400, 'status is not 500': (r) => r.status !== 500, 'response time < 200ms': (r) => r.timings.duration < 200, });};

มี Version GUI ด้วยนะ github.com/grafana/k6-studio


  • JMeter ตอนแรก พวกได้ Workload Model ให้ AI มัน Gen ให้ ไม่รู้เรื่องเลย 5555 พอมากด UI เข้าใจและ
  • wrk ใช้สำหรับลองง่ายๆ ก่อนดู Cap เบื้องต้น ถ้าทำมากกว่านั้นภาษา lua เขียน

นอกจากนี้ ถ้าใครใช้ Postman มันมีตัว Perf Test จะ แต่อาจจะติด Limit Concurrent การยิง ต้องเสียเงินเพิ่ม กลับกัน K6 เหมือนออกตัว Studio มาด้วย อาจจะเข้ามาทำแบบ Post

ตอนแรกเขียน 2 ทำไมงอก 555


📌 Collect Result ยังไง เครื่องตัวเอง หรือ หลายเครื่องยิงเอง ตรงนี้พี่ปุ๋ย พี่บอม มีพา Demo

  • เอา Local Report จาก K6 / JMeter
  • รวมถึงเอาผลมาทำเป็น Centralize จะได้เก็บที่เดียว และดูภาพรวมได้ทั้งหมด ใช้ตัว LGTM Stack อย่างตัว
    - Prometheous/Mimir - เก็บ Time Series ที่ได้จากการ Test แต่ตัว JMeter ไปทาง InfluxDB จะดีกว่า เพราะ JMeter ทดของไว้ในนั้นตอนรัน
    - Grafrana มาแสดงผล
    - Sample ของพี่ปุ้ย github.com/up1/workshop-perfor…


สุดท้ายอย่าลืมเก็บของลงใน Source Control ด้วย เป็นไปได้ควรอยู่ที่เดียวกับ Dev


PT: Run Tests (🤺ACT / ASSERT🤺)


  • ถ้าพร้อมแล้วก็ลุยทดสอบตาม Workload Model ที่เลือกไว้ เช่น เจอ load เยอะ ช่วย 11pm เมื่อวาน - ตี 2 วันถัดไป และอีกช่วง 9 โมงถึงบ่าย 2 รันทิ้งไว้ตามเวลานั้นๆเลยครับ
  • การ Run Test ให้ใช้แบบ CLI ถ้ากดจาก GUI ตัว UI อาจจะเดี้ยงก่อน
  • Load Injector แยก server หรือ ใช้ตัวเล็กๆ หลายตัว มาแบ่งๆ แต่คุยกับ network จะได้ไม่โดย Filter ออกไป และก็การสร้าง Virtual User มันใช้ Mem Tools มันใช้ Mem ถ้าเครื่องยิงไม่แรงพอ คนยิงตายเองก่อน
  • พวก load balance / api gw เป็นไปได้ ควรตัดออกไปก่อน จะได้รู้ว่า App มันรับได้จริงๆ เท่าไหร่ อาจจะโดนกันไป


PT: Analyst Result


เอาผลลัพธ์จาก Test Report มาดู เข้า Request Sucess / Fail หรือ รวมถึงดูจากข้อมูลที่ Percentile ที่เท่าไหร่
K6Jmeter
นอกจากนี้แล้วในช่วงเวลาเดียวกัน เราสามารถไปดูจากส่วน Observability System ได้ ว่าช่วยเวลาที่มีปัญหาจาก Perf Test Trace เวลาเดียวกัน Trace มันไปตายในจุดไหน เช่น App ตาย ส่วน DB เหงาไม่มีใครมา Query เป็นต้น
Grafana Prometheus StackFilter By TestId

PT: Tunning & Change Config


อันนี้ใน Class ไม่ได้สอน ผมเข้าใจว่า ถ้า Analyst Result ได้ แล้วไปดู Log Trace ว่าช้าตรงไหนเจอ เราไปแก้ Code หรือ Config ได้ ครับ

สำหรับ Class นี้จะเน้นสอนการคิดนะ เข้าใจส่วน Tools มาเสริมการใช้งานเบื้องต้นครับ เข้าใจมากขึ้นเยอะ ว่าที่เค้า Report มาให้ปรับๆ มันเป็นยังไง ขอบคุณทีมงานมากๆครับ


Reference


#performance #Observability #PerfTest




x.com/RonallChersan/status/193… สถานีที่ไทย โฆษณาเยอัเกินไปจริงๆ😞


Grove Crane Parts: The Foundation of Safe and Reliable Operations


For Grove cranes, using genuine Grove crane parts is what keeps the job site safe and the project on track.

There's a quiet majesty to a crane at work—its towering frame gliding through the air, hoisting heavy loads with a precision that feels almost effortless. You might watch it from the edge of the site, maybe munching on a snack, and marvel at how it places steel beams with pinpoint accuracy. But that performance hinges on the smallest components. For Grove cranes, using genuine Grove crane parts is what keeps the job site safe and the project on track.

When Small Oversights Become Big Problems


I've spent enough time around construction sites to know that the little things can cause the biggest disruptions. I once saw a job stall for hours because someone used a mismatched fitting in a hydraulic system—small mistake, huge headache. With cranes, the risks are even greater. A single subpar part can turn a smooth lift into a costly delay or a serious safety issue.

Why Grove Cranes Need Precision Parts


Grove cranes are built for the toughest jobs, trusted for their strength and reliability. But even the best crane is only as good as its parts. Think of it like a high-end watch: every gear has to be perfect for the hands to keep moving. Grove crane parts are designed specifically for these machines, ensuring they can handle heavy loads and constant use without faltering.

The Risk of Cutting Corners


A generic part might seem like a quick fix. It might even look identical to the real thing. But as one mechanic told me, "A cheap part is like a cheap ladder—it'll hold you up until it doesn't." Subtle differences in quality or design can lead to uneven performance, faster wear, or sudden failure. That's not a chance you take when a crane's lifting tons of material.

A Lesson from a Near-Disaster


A few years ago, a crew in Colorado made a costly mistake. Trying to save money, they ordered a replacement part from an unverified crane parts supplier. It wasn't a genuine Grove part, but it was cheaper, so they took the risk. During a heavy lift, the crane's slew mechanism hesitated. No one was hurt, but the site shut down for days, and the repair costs far exceeded the savings. A quality Grove crane part would've kept things running smoothly.

More Than Just Safety


Safety is the top reason to choose quality parts—no one wants to risk lives. But Grove crane parts do more than prevent accidents. They keep the crane operating smoothly, responding quickly, and running without unexpected hiccups. Operators can work with confidence, and the project stays on schedule, saving time and money.

The Value of Genuine Parts


Choosing genuine Grove crane parts isn't about spending more—it's about spending smart. These parts are engineered for Grove cranes, tested for durability, and built to last. A trusted crane parts supplier ensures you get components that fit perfectly and perform reliably, reducing the risk of breakdowns or safety issues.

The Payoff of Quality


In construction, the smallest choices often have the biggest impact. Quality Grove crane parts might not get much attention when everything's running well, but they're the reason your crane lifts with precision, moves without hesitation, and keeps your crew safe. They're why the job gets done on time and why everyone can focus on their work instead of worrying about equipment. Choosing the right parts is a small decision that delivers big results.



เชื่อแล้วว่าจิตใจส่งผลกับร่างกายมากกกก ไปเที่ยว9วันร่างกายคงเกร็งกิเดสอุนแบบเหนียมๆ แต่พอกลับถึงบ้านปุ๊บอุนแตกยับ ร่างกายrelaxed55555555


✨ A Sprinkle of JoyousJoyness ✨

Yep, that about sums it up.

Have a JoyousJoyfulJoyness day!

#happy #cat #blackcat #babyanimal #cute #truth #joyousjoyness #caturday




เมื่อสมัยนพดล ปัทมะ ผมซึ่งยังเลือก ปชป. (และยังมีเวลา) อยู่ อยากรู้ความจริงเลยไล่อ่านเอกสารเยอะแยะกรณีปราสาทพระวิหาร จนสรุปได้ว่านพดลไม่ได้ทำให้ไทยเสียดินแดน แต่ตอนนั้นคุยกับใครไม่รู้เรื่องเลย ตอนนี้เขาออกมาอธิบายเองตามความเป็นจริง ก็คิดว่าจะมีคนรู้เรื่องบ้าง แต่อ่านคอมเมนต์แล้วสิ้นหวัง
youtube.com/watch?v=G5Vl7EHMhI…

ชาตินิยมทำให้คนละเลยความจริง

SukinoVERSE reshared this.



China tightens internet controls with new centralized form of
virtual ID

Politicians of both parties in the U.S. would LOVE to have this here!

cnn.com/2025/06/20/tech/china-…



อ่าน Thesis ของผู้สร้าง Nix แล้วม่วนมาก เห็นภาพนี้แล้วสยองดี
แปะ link: edolstra.github.io/pubs/phd-th…


My knee-jerk reaction to this article from @adamshostack was a cynical [citation needed] re “artists from all mediums emphatically support the use of AI.”

On further reflection…well, that’s still my response to the eyeball-grabbing lede, yes, but the actual article is what I wish we’d had instead of this inane hype avalanche:

Artists poking at the new thing, playing with it, finding its possibilities, critiquing it, problematizing it, asking us to ask what it is, helping us see it with fresh eyes from many angles. infosec.exchange/@adamshostack…

in reply to Paul Cantrell

Maria Montessori:

❝Our care of the child should be governed, not by the desire to make him learn things, but by the endeavor always to keep burning within him that light which is called intelligence.❞

❝We cannot know the consequences of suppressing a child's spontaneity when he is just beginning to be active. We may even suffocate life itself. That humanity which is revealed in all its intellectual splendor during the sweet and tender age of childhood should be respected with a kind of religious veneration. It is like the sun which appears at dawn or a flower just beginning to bloom. Education cannot be effective unless it helps a child to open up himself to life.❞

9/

in reply to Paul Cantrell

More Montessori:

❝Imagination does not become great until human beings, given the courage and the strength, use it to create.❞

And here’s a kicker:

❝Establishing lasting peace is the work of education; all politics can do is keep us out of war.❞

Put that last thought in the context of arts and education being deeply intertwined, and oligarchy seeking to dismantle both, and…well….

/end

This entry was edited (3 weeks ago)


3 people in Madhya Pradesh, India, died while stuck in a THIRTY TWO hour traffic jam along an intercity highway.


The highway in question is cratered with potholes due to shoddy, cut-rate roadwork that disintegrates at the first sign of inclement weather.

The worst part? There's a train between those same two cities, but the state of the railways in this country is beyond the pale, ironically because the government is pretending to invest in shiny new roads that...are cratered with potholes and disintegrate at the first sign of inclement weather.



GPD MicroPC 2 with Intel N250 Brings Multi-Port Connectivity to Ultra-Mobile Design lxer.com/module/newswire/ext_l…

in reply to Rich

I tried to reason with these woke lunatics, no reason to do it anymore. Just laugh at them, call them funny names (back) and ignore them.
in reply to Roland Häder🇩🇪

See here, just one of many examples:


H.O.F. - 2025-06-30 06:24:32 GMT

@roland
Nobody here likes itAny proof of this bold statement? statistics? Something besides a group of bot accounts?

Do what you like but leave me out of it.

Fuck off then



@roland
>Nobody here likes it

Any proof of this bold statement? statistics? Something besides a group of bot accounts?

> Do what you like but leave me out of it.

Fuck off then




Linux 6.16-rc4 Released With AMD Cleaner Shader For More GPUs, Bcachefs Changes

Linus Torvalds just released Linux 6.16-rc4 as we prepare to close out the first half of 2025 and hitting roughly one month until the Linux 6.16 stable release...
phoronix.com/news/Linux-6.16-r…



Meet Wayback: A Bridge Between X Desktops and Wayland lxer.com/module/newswire/ext_l…


ดูคอนเสิร์ตของวง Seal Pillow ครั้งแรกวันนี้ (ณ Blueprint Livehouse) ก่อนหน้านี้ไม่เคยรู้เลยว่าเขาหน้าตาเป็นยังไง วงนี้คือวงไหน ร้องเพลงอะไร จนกระทั่งมายืนฟัง Live ของจริง ก็พบว่าตัวเองรู้จักไปแล้ว 5 เพลงได้ แบบไม่เคยเชื่อมโยงเลยว่าใครร้องและเพลงชื่ออะไร

เอ้ยย ... เขา debut มา 12 ปีแล้วนะ!

Seal Pillow มีความสนุก มีความเด็ก ความสดใสวัยเรียนอยู่ในตัวเสมอ บนเวทีดูมีชีวิตชีวามาก แม้เขาเองจะเคลมหลายรอบว่าอายุไม่ใช่น้อยแล้ว ใครยังไม่เคยลองฟังอยากแนะนำให้มาทำความรู้จักกันคับ

in reply to obchoey

ปล. บางครั้งนักร้องอาจจะทำท่าคล้ายรำไทเก็กอยู่ แต่จริงๆแล้วกำลังเต้นคับ


Did Gemini CLI Drop Acid Last Night? lxer.com/module/newswire/ext_l…



Fedora’s 32-bit (i686) Support Withdrawal Postponed – Here’s Why lxer.com/module/newswire/ext_l…


New to #AI? Discover how it all began!

Take a journey through key milestones in AI’s evolution and how #opensource shaped its future. Watch Harish Pillay break it down in this insightful session.

Click here: youtu.be/g5iOimfffKY



Wine-Based Hangover Project Drops QEMU In Favor Of FEX & Box64 For Emulation

Building off Friday's release of Wine 10.11 for running Windows games and applications on Linux is now Hangover 10.11 for this Wine-based software used for running Windows games/applications cross-architecture such as on AArch64/ARM64 systems...
phoronix.com/news/Hangover-10.…





Ich habe nach der Anleitung von @Herbert Hertramph DietPi und Samba installiert.
Auf den Hauptordner usb-hdd und dietpi komme ich problemlos drauf. Wenn ich allerdings unter usb-hdd einen neuen Ordner anlege, die Berechtigungen entsprechend vergebe und die smb.conf anpasse, komme ich dort auf den Unterordner nicht drauf.

Unter ZorinOS gebe ich im Dateimanager folgende Adresse an
smb://192.168.178.2/thomas
Dann erscheint die Anmeldung. Dort gebe ich den Nutzernamen thomas und das Samba Kennwort ein. Es erscheint die Meldung, dass ich keine Berechtigung habe.

Was mache ich falsch?

drwx------ 2 thomas thomas 4096 29. Jun 14:09 thomas

smb.conf
[global]

	workgroup = WORKGROUP
	server string = %h server
	dns proxy = no
	log file = /var/log/samba/log.%m
	max log size = 1000
	logging = syslog@1

	panic action = /usr/share/samba/panic-action %d

	security = user
	passdb backend = tdbsam
	obey pam restrictions = yes
	unix password sync = yes

	passwd program = /usr/bin/passwd %u
	passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
	pam password change = yes
	map to guest = bad user

	load printers = no
	printcap name = /dev/null
	disable spoolss = yes

[dietpi]
	comment = DietPi Share
	path = /mnt/dietpi_userdata
	browseable = yes
	create mask = 0664
	directory mask = 0775
	valid users = samba
	writeable = yes
	max connections = 8

[usb-hdd]
	comment = USB-Laufwerk Freigabe
	path = /mnt/usb-hdd
	browseable = yes
	writable =yes
	only guest = no
	create mask = 0777
	directory mask = 0777
	public = no
	valid users = samba

[thomas]
  comment = Persönlicher Ordner von Thomas
  path = /mnt/usb-hdd/thomas
  valid users = thomas
  read only = no
  create mask = 0700
  directory mask = 0700
  browseable = yes


#nas #homeserver #raspberry #dietpi #samba

in reply to Thomas

Ist es möglich dass Dateien per #Samba auf der externen Festplatte und lokal abgespeichert werden?
Oder sollte ich da unter #DietPi lieber etwas anderes nutzen?


กำลังคิดว่าจะโฮส pleroma เล่นๆไว้ที่ kuyrai.com เพราะไหนๆก็จดโดเมนมาแล้วไม่ได้ใช้ทำไร แถม Hetzner ก็ถูกดี :spacemisccattomg:


จริงนะ จีนเป็นไรกับ power bank นักหนาในเมื่อ power bank กากๆก็ผลิตในจีนหมดเลย :bunthink:

x.com/PalmGuin/status/19392937…



เงยหน้าเจอพอดี


AMD Prepares Linux Driver Support For New APUs Still Relying On RDNA1 Graphics

It looks like AMD is preparing to introduce some new APUs/SoCs still relying on RDNA1-based graphics with open-source GPU driver patches posted this week extending the "Cyan Skillfish" support to some new APU devices...
phoronix.com/news/AMD-More-Cya…