Skip to main content



ซัมซุงจัดดีลพิเศษ! ลงทะเบียนเป็นเจ้าของ The new Galaxy กลุ่มแรกของโลก ซื้อ e-Voucher เพียง 500 บาท รับส่วนลดและเงินคืนรวม 3,000 บาท https://digitalmore.co/ซัมซุงจัดดีลพิเศษ-ลงทะเ/


มาเลเซียเปิดตัวแพลตฟอร์ม Startup ASEAN เต็มรูปแบบชูวิสัยทัศน์ขับเคลื่อนการเติบโตทางเศรษฐกิจทั่วภูมิภาค https://digitalmore.co/มาเลเซียเปิดตัวแพลตฟอร/



kagi maintenance แล้วก็โง่เลย search อะไรไม่ได้


#pastpuzzle 343
🟩🟩🟥🟨 (-2)
🟩🟩🟩🟩 (0)
▪️▪️▪️▪️
▪️▪️▪️▪️

2/4 🥈
pastpuzzle.de



Orange Pi Nova Teased with Loongson 2K3000 as Loongson Expands Product Line lxer.com/module/newswire/ext_l…


กุสูนกับเว็บการบินไทยว่ะ booking ยาวเหยียดเช็คแล้วเช็คอีกกด next เว็บเจ๊ง ค
in reply to m

รอบนี้ไปไหนอีก บินเก่งมาก


โถ่ นึกว่ากลายเป็นพวกเดียวกันแล้ว


gemini pro นี่ show thinking มันจะเหมือนว่ามันคิดตามลำดับถูก แต่มันไม่โชว์กระดาษทด ในขณะที่ตัวที่ openrouter auto เอามาให้ลองนี่มันเหมือนเห็นกระดาษทดมันแล้วเลยเข้าใจได้ง่าย


จะเล่นเกม ไปถาม optimization สูตรคราฟให้กดน้อยที่สุดจาก gpt 4.1 nano แล้วมันลืมคิดว่าคราฟไอเทมเสียตังด้วย เลยหมดตูด (ดีฝากเงินในแบงค์ไว้)

ไปถาม gemini 2.5 pro ในไอดี workspace basic ถามแป๊บเดียวบอกหมดโควต้าวันนี้

เลยนึกได้ว่าเออมี openrouter auto เหลือ ไปถามอันนั้น ไม่รู้มันใช้โมเดลไร คิดละเอียดดี จบเลย



In my Portable Puzzle Collection, it was recently (a few weeks ago) the 20th birthday of the game "Mines": a reimplementation of Minesweeper which ensures every grid can be solved by reasoning rather than guesswork. The first click in a completely blank grid is guaranteed to be safe, and to open an area of more than one clue, and after that, you can always identify a safe square to open next by thinking about the currently visible clues.

This makes it possible to generate grids with a much higher density of mines than standard randomised Minesweeper, such as the example shown here with 99 mines in only a 16×16 grid. I actually didn't predict that this would be possible when I wrote the grid generator originally: I only expected to be able to play on settings like the standard Windows ones, without those nasty last-minute frustrations. The ability to turn up the density by more than a factor of 2 was a very pleasant surprise – my algorithm was far more effective than I had anticipated!

The odd thing about Mines is: in the past 20 years, this one game has received far more bug reports about insoluble game instances than any other puzzle in my collection. Very likely more than all the other games *put together*.

But not one of those reports has turned out to be a real bug in the grid generation. In cases where they sent a save file or a game ID, I generally played through the game myself to make sure; if they only sent a screenshot, I've always at least pointed out something I could see in the picture. *Everybody* who sent this kind of report turned out to have missed something.

Happy 20th birthday, Mines!



Porcelain vs. Ceramic: The Best Tile for Your Luxury Project


Both are often pitched as premium bathroom tiles, sitting side by side in stores, but they're not the same. Choosing the right one is key for spaces that need to impress and last.

Tackling a bathroom renovation, a kitchen upgrade, or a flooring refresh? You're likely after tiles that look sleek, feel high-end, and stand up to daily use. That's where luxury bathroom tiles come in.

The question everyone faces: Porcelain or ceramic? Both are often pitched as premium bathroom tiles, sitting side by side in stores, but they're not the same. Choosing the right one is key for spaces that need to impress and last.

Here's the no-frills breakdown to help you decide.

What Sets Them Apart?


Porcelain is a type of ceramic, but it's denser, fired at higher temperatures, and less absorbent. This makes it tougher, more resistant to cracks, and better suited for demanding conditions. Ceramic is lighter, easier to work with, and typically more budget-friendly.

Think of porcelain as ceramic's sturdier, more elegant sibling.

Porcelain's Edge in Luxury


For high-end spaces, porcelain often takes the win. It's built for durability, making it ideal for premium bathroom tiles or high-traffic floors. You'll see it in luxury homes, upscale hotels, or custom-designed offices. It handles radiant heating, heavy foot traffic, and even outdoor settings effortlessly.

Porcelain's low water absorption makes it perfect for wet areas like bathrooms or patios. It resists mold, stains, and swelling better than ceramic. Plus, it can mimic high-end materials like marble or stone with less maintenance.

Where Ceramic Shines


Ceramic isn't second-rate—it's just better for specific uses. It's great for walls, backsplashes, or low-traffic areas. It's easier to cut, install, and more affordable.

But for luxury bathroom tiles or busy floors? Ceramic might not deliver the durability or premium vibe you're aiming for.

Style and Feel


Both porcelain and ceramic offer endless styles—matte, glossy, textured, or patterned. You can find premium bathroom tiles in either category. But porcelain has a solid, weighty feel that elevates a space. It's like the difference between a good chair and one that feels crafted—one just feels more luxurious.

The Cost Factor


Porcelain costs more upfront. That's the reality. But its longevity and low maintenance can save you money over time, with fewer repairs or replacements needed.

On a tight budget? Ceramic works well for walls or less demanding spaces. But for a luxury space, cutting corners on materials can hurt the final result.

Why Your Tiles Supplier Matters


Tile quality varies widely. A reliable tiles supplier will guide you to premium bathroom tiles that fit your project. They'll share details on the tile's origins, durability, and performance—not just push a sale.

Shopping online? Check reviews thoroughly. In a showroom? Ask about quality and suitability. A good tiles supplier ensures you get tiles that look great and last.

The Bottom Line


For high-end, high-use areas, porcelain is the smarter pick. It's tougher, more elegant, and perfect for luxury bathroom tiles. Ceramic is fine for walls or secondary spaces but doesn't match porcelain's durability or upscale feel.

Start with a trusted tiles supplier to find the right tiles. It's about creating a space that's as durable as it is stunning.



AfD vs. BSW: Ciceros „Der ungerechteste Frieden ist immer noch besser als der gerechteste Krieg“ als Leitmotiv aktueller Wählergunst! riehle-news.de/afd-vs-bsw-cice… Während Friedrich Merz in der Weltgeschichte unterwegs ist, debattiert die hiesige Öffentlichkeit nicht etwa über seine persönliche Kampfbereitschaft an der Front. Stattdessen spielt sich in den Umfragen an


ÖRR-Prioritäten: Während panisch Hitzewelle Nummer 8 anrollt, werden Schwimmbäder zur verschwiegenen Hochrisikozone! riehle-news.de/oerr-prioritaet… Verzichtet man über einen gewissen Zeitraum darauf, die Öffentlich-Rechtlichen zu konsumieren und sich nicht in der "Tagesschau" oder "heute"-Sendung über das Weltgeschehen zu informieren, wird man im Zweifel rasch zur Erkenntnis


Было приятно присоединиться к группе ЕС на Прайд Параде в Сан-Франциско! Вся пятничасовая акция была просто невероятной. С Прайдом!

#ПрайдПарад #СанФранциско #СчастливогоПрайда #ЛГБТК #ЕСПрайд

in reply to Roland Häder🇩🇪

@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

in reply to H.O.F.

@H.O.F. Okay, troll. Send Soros my greetings, same words you used against me. Maybe you and your fetish-lovers love it but others find it annoying and disgusting but they keep quiet. I don't have enough time to entertain you here.


อนิเมะทีวี ลาซารัส (Lazarus) เผยโปสเตอร์ใหม่ หลังจากฉายตอนที่ 13 (ตอนจบ)

สามารถรับชมได้ที่ iQIYI, TrueID



Wine-Based Hangover Project Drops QEMU In Favor Of FEX & Box64 For Emulation lxer.com/module/newswire/ext_l…


คนสร้าง netty.io นี่อยู่ linecorp หรอเนี่ย


เรียกกู้ภัยมาช่วยแมว ต้องโทรเบอร์ไหนอะคะ
Unknown parent

mastodon - Link to source
Mameaw
@veer66 โทรไปละค่ะ 199


อนิเมะ CITY THE ANIMATION เผยโปสเตอร์ตัวละคร

- Nagumo Midori (CV: Komatsu Mikako)
- Niikura Ayumu (CV: Toyosaki Aki)
- Izumi Wako (CV: Ishikawa Yui)

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





อนิเมะทีวี วิญญาณคร่ำครวญอยากวางมือแล้ว ~วิธีปั้นปาร์ตี้สุดแกร่งโดยฮันเตอร์สุดอ่อน~ (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.