# Week 13: Performance Testing

## Learning Objectives

หลังจากเรียนจบสัปดาห์นี้ นักศึกษาจะสามารถ:

1. อธิบายประเภทของ Performance Testing และเลือกใช้ได้เหมาะสม
2. วิเคราะห์เมตริกส์ประสิทธิภาพ (Performance Metrics) และระบุคอขวด (bottlenecks)
3. ใช้ k6 ในการทำ Load Testing
4. เข้าใจ Visual Regression Testing และความสำคัญ (Optional)
5. ใช้ Playwright สร้าง Visual Tests (Optional)
6. วิเคราะห์ผลการทดสอบและเสนอแนะการปรับปรุง

---

## การเชื่อมต่อกับสัปดาห์ที่ 12

**สัปดาห์ที่ 12 (ที่แล้ว):** การทดสอบความปลอดภัย

- พบและจัดทำเอกสารช่องโหว่ด้านความปลอดภัย
- ระบุปัญหาการฉีด SQL, XSS, และปัญหาการยืนยันตัวตน (Authentication)

**สัปดาห์ที่ 13 (สัปดาห์นี้):** การทดสอบประสิทธิภาพ

- เมื่อ API มีความปลอดภัยแล้ว ให้ทดสอบ **ความเร็ว**
- API การจัดการห้องสมุดเดียวกัน → มุมมองการทดสอบที่ต่างออกไป
- ทดสอบพฤติกรรม **ภายใต้โหลด**

```
ทดสอบ API เดียวกันจาก 3 มุมมอง:
  Week 11: หน้าที่ (ทำงานได้ไหม?)
  Week 12: ความปลอดภัย (ฉันสามารถทำลายได้ไหม?)     ← เสร็จสิ้น
  Week 13: ประสิทธิภาพ (ทำงานเร็วแค่ไหน?)  ← สัปดาห์นี้
```

---

# การเชื่อมโยงกับสัปดาห์ที่ 12

---

**คำถามสำหรับชั้นเรียน:**
ในสัปดาห์ที่ 12 เราพบช่องโหว่อะไรบ้าง?

- การฉีด SQL ในแบบฟอร์ม เข้าสู่ระบบ ค้นหา เพิ่มข้อมูล
- XSS ในชื่อหนังสือ
- การจัดการเซสชันที่อ่อนแอ
- ข้อมูลที่ฮาร์ดโค้ด

---

## เหตุใดประสิทธิภาพเทียบกับความปลอดภัยจึงสำคัญ

หากคุณทดสอบประสิทธิภาพบนโค้ดที่มีข้อบกพร่อง:

- อัตราข้อผิดพลาดสูง → เป็นข้อบกพร่องหรือคอขวด?
- การตอบสนองช้า → โค้ดช้าหรือการฉีด SQL ที่ DB?
- ไม่สามารถแยกแยะปัญหาประสิทธิภาพที่แท้จริงจากข้อบกพร่อง

---

# ส่วนที่ 1: พื้นฐานการทดสอบประสิทธิภาพ

---

## 1.1 การทดสอบประสิทธิภาพคืออะไร?

### บทนำ

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

### ความนิยาม

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

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

แทนที่จะใช้ประเมินคุณลักษณะที่ไม่ใช่เชิงหน้าที่ (Non-Functional Attributes) เช่น ความเร็ว ความเสถียร ความสามารถในการปรับขนาด และการใช้ทรัพยากร

### คำถามหลักที่การทดสอบประสิทธิภาพเป็นเครื่องช่วยตอบ

การทดสอบประสิทธิภาพช่วยให้ทีมพัฒนาซอฟต์แวร์พบคำตอบสำหรับคำถามสำคัญดังต่อไปนี้:

**1. ความเร็วในการตอบสนอง (Response Time)**

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

**2. ความสามารถในการปรับขนาด (Scalability)**

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

**3. เสถียรภาพและความทนทาน (Stability and Resilience)**

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

**4. การใช้ทรัพยากร (Resource Utilization)**

- ระบบใช้ CPU อย่างมีประสิทธิภาพเพียงใด
- การใช้หน่วยความจำมีการสูญเปล่า(Waste) หรือจำนวนอ่างหนึ่ง
- เครือข่ายและปริมาณการส่งข้อมูลคืออะไร
- ความต้องการพื้นที่จัดเก็บข้อมูล (Storage) เพิ่มขึ้นอย่างไร

### ความสำคัญของการทดสอบประสิทธิภาพ

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

**ผลกระทบทางธุรกิจ:**

บริษัทชั้นนำทั่วโลกต่างให้ความสำคัญกับประสิทธิภาพเนื่องจากสัมพันธ์กับการสูญเสียรายได้โดยตรง:

- **Amazon:** การศึกษาพบว่าความล่าช้า 1 วินาที ส่งผลให้สูญเสีย 1.6 พันล้านดอลลาร์ต่อปี หรือเทียบเท่า 1.6% ของรายได้รวม
- **Google:** ช้า 500 มิลลิวินาที ส่งผลให้จำนวนการค้นหา (และรายได้จากโฆษณา) ลดลง 20%
- **eBay:** ทุก 100 มิลลิวินาที ของความบ้าน ส่งผลให้การสูญเสีย 0.5% ของยอดขายรายปี

**ผลกระทบต่อการใช้งานจริง:**

เมตริกส์พฤติกรรมผู้ใช้ (User Behavior Metrics) แสดงว่า:

- 53% ของผู้ใช้เว็บแบบมือถือจะละทิ้งเว็บไซต์ที่ใช้เวลาในการโหลดมากกว่า 3 วินาที
- 1 วินาที ของความบ้านอาจส่งผลให้ความพึงพอใจของผู้ใช้ลดลง 7%
- 30% ของผู้ใช้ทำการเลิกใช้บริการหลังจากมีประสบการณ์ที่ช้า

**ปัญหาประสิทธิภาพที่พบบ่อยในระบบการผลิต:**

1. **การตอบสนองช้า (Slow Response Time)**
   - ผู้ใช้ต้องรอ กล่อม โดยไม่มีการตอบรับ ส่งผลให้ความหงุดหงิด
   - ลดความพึงพอใจของผู้ใช้
   - ส่งผลเสีย ต่ออัตราการกลับมาใช้งานใหม่ (Retention Rate)

2. **การขัดข้องของระบบภายใต้โหลดสูง (System Crash Under Peak Load)**
   - สูญเสียข้อมูล
   - ส่งผลให้ต้องชดเชยค่าสูญหายแก่ผู้ใช้
   - ฟื้นฟูหรือสร้างความไว้วางใจใหม่

3. **ต้นทุนการให้บริการสูง (High Operational Cost)**
   - ใช้ทรัพยากรการคำนวณ (CPU) มากเกินความจำเป็น
   - ต้องการเซิร์ฟเวอร์เพิ่มเติมเพื่อรองรับภาระงาน
   - ค่าไฟฟ้า การแช่เย็น เพิ่มขึ้น

4. **ประสบการณ์ผู้ใช้ที่ไม่ดี (Poor User Experience)**
   - ผู้ใช้มีความสามารถในการทำงานลด ลงเนื่องจากการรอ
   - บิดเบือนของเป้าหมายผู้ใช้ (ไม่สอดคล้องกับความคาดหวัง)
   - ส่งผลต่อการสูญเสียลูกค้า และโอกาสทางธุรกิจ

### ความสำคัญสัมพัทธ์: ประสิทธิภาพ เมื่อเทียบกับคุณสมบัติอื่นๆ

ประสิทธิภาพไม่ควรจะนำมาพิจารณาแยกออกมาจากด้านอื่นทั้งนั้น แต่ควรที่จะมองเห็นในบริบทที่กว้างขึ้น ศีลเมตริกส์ยืม (Non-Functional Requirements) อื่นๆ เช่น ความปลอดภัย เป็นต้น เช่นเดียวกัน:

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

จึงจำเป็นที่ต้องคำนึงถึงทั้งสองด้านพร้อมๆ กัน

---

## 1.2 ประเภทของการทดสอบประสิทธิภาพ

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

---

### 1. การทดสอบโหลด (Load Testing)

**วัตถุประสงค์:** การทดสอบโหลดมีวัตถุประสงค์เพื่อประเมินประสิทธิภาพของระบบเมื่ออยู่ภายใต้สภาวะโหลดปกติหรือโหลดที่คาดหวังตามการใช้งานจริง

**นิยาม:** โหลดที่คาดหวัง (Expected Load) หมายถึงตัวเลขโหลดจราจรที่ประมาณการจากข้อมูลทางสถิติหรือความต้องการที่คาดว่าจะเกิดขึ้นในการใช้งานจริงของระบบ

**สถานการณ์การใช้ทั่วไป:**

วันปกติของการใช้งานห้องสมุด:

- ผู้ใช้พร้อมกัน: 50 คน
- อัตราคำขอ: 200 ครั้งต่อนาที
- ระยะเวลาการดำเนินการ: 8 ชั่วโมง

**เมื่อใช้การทดสอบโหลด:**

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

**ตัวอย่างการออกแบบการทดสอบ: ระบบจัดการห้องสมุด**

สถานการณ์การทดสอบโหลด:

- ผู้ใช้ 50 คนค้นหาและดูรายละเอียดหนังสือ
- ผู้ใช้ 20 คนใช้งานฟีเจอร์ค้นหาขั้นสูง
- ผู้ใช้ 10 คนทำการยืมหนังสือ
- ระยะเวลาการทดสอบ: 30 นาที
- เกณฑ์ความสำเร็จ: ทุกการดำเนินการตอบสนองภายในเวลา 2 วินาที

**วิธีการประเมินผลการทดสอบ:**

- เวลาตอบสนองเฉลี่ย (Mean Response Time) ต้องไม่เกิน 1 วินาที
- เปอร์เซ็นไทล์ที่ 95 (P95) ต้องไม่เกิน 1.5 วินาที
- อัตราข้อผิดพลาดต้องไม่เกิน 0.1%

---

### 2. การทดสอบความเครียด (Stress Testing)

**วัตถุประสงค์:** การทดสอบความเครียดมีวัตถุประสงค์เพื่อค้นหาจุดพังทลายของระบบ (Breaking Point) - ค่าโหลดที่มากที่สุดที่ระบบสามารถรองรับได้ก่อนที่จะมีการล้มเหลวหรือประสิทธิภาพลดลงอย่างมีนัยสำคัญ

**นิยาม:** จุดพังทลายคือจุดที่ระบบไม่สามารถปรับตัวให้เข้ากับโหลดที่เพิ่มขึ้นได้อีก ทำให้มีการตัดปลายคำขอ (connection timeout) หรือข้อผิดพลาดเพิ่มขึ้น

**สถานการณ์การทดสอบ:**

การเพิ่มโหลดอย่างค่อยเป็นค่อยไป:

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

**สิ่งที่ได้เรียนรู้จากการทดสอบความเครียด:**

- ความสามารถสูงสุดของระบบ (Maximum Capacity) - กี่ผู้ใช้ที่ระบบสามารถรองรับได้
- พฤติกรรมการล้มเหลวของระบบ:
  - การปรับตัวอย่างสง่างาม (Graceful Degradation): ระบบเสื่อมสภาพอย่างค่อยเป็นค่อยไป เช่น ผลลัพธ์ส่งกลับช้าลง แต่ยังคงตอบสนอง
  - การล้มเหลวทันที (Abrupt Failure): ระบบหยุดทำงานเอกสาร - สถานการณ์ที่ไม่พึงประสงค์
- เวลาในการกู้คืน (Recovery Time): ใช้เวลากี่นาทีในการฟื้นตัวกลับมาทำงานปกติหลังจากล้มเหลว
- วิธีการจัดการข้อผิดพลาดของระบบและการลำดับความสำคัญของข้อมูล

**ตัวอย่าง: ระบบจัดการห้องสมุด**

ออกแบบการทดสอบความเครียด:

- เริ่มด้วยผู้ใช้พร้อมกัน 100 คน และรองรับได้ดี
- เพิ่มผู้ใช้เป็น 200 คน → 300 คน → 400 คน → 500 คน
- สังเกตว่าที่ 400 คนระบบเริ่มตอบสนองช้า
- ที่ 500 คนระบบหากไดล้มเหลว
- จุดพังทลาย (Breaking Point): ไม่เกิน 500 คน

เป้าหมาย: ระบบควรเสื่อมสภาพอย่างสง่างาม (ความสามารถลดลงค่อยเป็นค่อยไป) ไม่ใช่ขัดข้องทันที

---

### 3. การทดสอบจุดสูงสุด (Spike Testing)

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

**ความแตกต่างจากการทดสอบความเครียด:**

- การทดสอบความเครียด: เพิ่มโหลดทีละเล็กน้อยอย่างค่อยเป็นค่อยไป
- การทดสอบจุดสูงสุด: เพิ่มโหลดอย่างกะทันหันเป็นจำนวนมากตั้งแต่เริ่มต้น

**สถานการณ์การทดสอบ:**

```
ตารางเวลาโหลด:
- นาที 0-5: โหลดปกติ ผู้ใช้ 100 คน
- นาที 5-10: จุดสูงสุด ผู้ใช้ 1000 คน (เพิ่มขึ้น 10 เท่า)
- นาที 10-15: โหลดกลับปกติ ผู้ใช้ 100 คน
```

**ตัวอย่างในโลกแห่งความจริง:**

ปรากฏการณ์จุดสูงสุด:

- Black Friday/Cyber Monday: พนักงานออนไลน์มีความต้องการสูงมากพอดี ทำให้ผู้ก้ืนจำนวนมากเข้าไปพร้อมกัน
- การปล่อยผลสอบหรือการประกาศข้อมูลที่สำคัญ: ผู้ใช้ทั้งหมดพยายามเข้าไปดูแบบเดียวกันในเวลาเดียวกัน
- ผู้สร้างอิทธิพล (Influencer) แนะนำแอปพลิเคชัน
- เหตุการณ์ตามนิตยาการกีฬา หรือความบันเทิง: ผู้ใช้หลายล้านคนพยายามเข้าไปดูแบบพร้อมกัน

**ตัวอย่าง: ระบบจัดการห้องสมุด**

ออกแบบการทดสอบจุดสูงสุด:

- สถานการณ์: มหาวิทยาลัยเผยแพร่เอกสารการศึกษาฉบับใหม่ในลิงก์เดียว
- ปกติ: ผู้ใช้ 20 คน
- จุดสูงสุด: ผู้ใช้ 500 คนพยายามเข้าถึงพร้อมกัน
- ระยะเวลาของจุดสูงสุด: 2 นาที แล้วกลับลงมาเป็น 20 คน

เกณฑ์ความสำเร็จ:

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

---

### 4. การทดสอบความทนทาน (Endurance Testing หรือ Soak Testing)

**วัตถุประสงค์:** การทดสอบความทนทานมีวัตถุประสงค์เพื่อประเมินเสถียรภาพของระบบเมื่อทำงานอย่างต่อเนื่องภายใต้โหลดปานกลางสำหรับช่วงเวลานาน (หลายชั่วโมง ถึง หลายวัน)

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

**สถานการณ์การทดสอบ:**

```
โหลดปานกลางสำหรับระยะเวลายาว:
- ผู้ใช้พร้อมกัน: 200 คน (ไม่ใช่จุดสูงสุด แต่ไม่ใช่โหลดต่ำ)
- ระยะเวลา: 24-72 ชั่วโมง (หรือยาวกว่านั้น)
- การตรวจสอบ: ติดตามหน่วยความจำ CPU การใช้เครือข่าย พื้นที่ดิสก์
```

**สิ่งที่เราค้นพบจากการทดสอบความทนทาน:**

หลุดรั่วหน่วยความจำ (Memory Leaks):

- โปรแกรมใช้หน่วยความจำเพิ่มขึ้นอย่างค่อยเป็นค่อยไปตลอดเวลาการทดสอบ
- ตัวอย่าง: หลังจาก 1 ชั่วโมงใช้ 500MB หลังจาก 24 ชั่วโมงใช้ 2GB
- ผลกระทบ: ในที่สุดระบบจะหมดหน่วยความจำและขัดข้อง

การใช้ทรัพยากรสิ้นสุด (Resource Exhaustion):

- Connection Pool (สระการเชื่อมต่อ) หมดเพราะการเชื่อมต่อเก่าไม่ได้ปิด
- Database Connection Timeout: ไม่สามารถเชื่อมต่อฐานข้อมูลได้อีก

การใช้พื้นที่ดิสก์เพิ่มขึ้น:

- ไฟล์บันทึก (Log Files) เติบโตอย่างไม่ได้ควบคุม
- ตัวอย่าง: บันทึก 1MB ต่อนาที = 1.4GB ต่อวัน

**ตัวอย่าง: ระบบจัดการห้องสมุด**

ออกแบบการทดสอบความทนทาน:

- ผู้ใช้พร้อมกัน: 50 คน (โหลดปานกลาง)
- ระยะเวลา: 8 ชั่วโมง (จำลองวันทำการหนึ่งวัน)
- การตรวจสอบทุก 30 นาที:
  - การใช้หน่วยความจำ: ต้องคงที่ไม่เพิ่มขึ้น
  - จำนวนการเชื่อมต่อ DB ที่ใช้งาน
  - ประสิทธิภาพของการสอบถาม

เกณฑ์ความสำเร็จ:

- ไม่มีการรั่วของหน่วยความจำ (memory usage คงที่)
- ประสิทธิภาพเสถียรตลอดระยะเวลา 8 ชั่วโมง
- อัตราข้อผิดพลาด: 0%

---

### 5. การทดสอบปริมาณ (Volume Testing)

**วัตถุประสงค์:** การทดสอบปริมาณมีวัตถุประสงค์เพื่อประเมินประสิทธิภาพของระบบเมื่อต้องจัดการกับปริมาณข้อมูล (Data Volume) ที่มหาศาล ซึ่งอาจรวมถึงปริมาณฐานข้อมูลขนาดใหญ่ หรือจำนวนบันทึกที่มากมาย

**นิยาม:** ปริมาณข้อมูลขนาดใหญ่ (Large Data Volume) หมายถึง ฐานข้อมูลที่มีเรกคอร์ดจำนวนมากหรือข้อมูลที่มีขนาดใหญ่โตขึ้น ซึ่งอาจมีผลต่อประสิทธิภาพของการสอบถาม

**สถานการณ์การทดสอบ:**

```
ฐานข้อมูลขนาดใหญ่:
- จำนวนหนังสือ: หลายล้านเล่ม
- จำนวนสมาชิก: หลายล้านคน
- จำนวนธุรกรรม: หลายล้านรายการ
- จำนวนบันทึกประวัติ: ข้อมูลสะสมหลายปี
```

**สิ่งที่ทดสอบ:**

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

**ตัวอย่าง: ระบบจัดการห้องสมุด**

ออกแบบการทดสอบปริมาณ:

ขนาดฐานข้อมูล:

- หนังสือ: 100,000 เล่ม
- สมาชิก: 10,000 คน
- ธุรกรรมการยืม: 1,000,000 รายการสะสม

การดำเนินการที่ทดสอบ:

1. ค้นหาด้วยเงื่อนไขที่ซับซ้อน:
   - ค้นหาหนังสือจากผู้แต่งหลายคน หมวดหมู่ เฉพาะหนังสือที่ตีพิมพ์ใน 5 ปีที่ผ่านมา
   - เกณฑ์ความสำเร็จ: ต้องส่งคืนผลลัพธ์ภายใน 3 วินาที

2. สร้างรายงานประจำปี:
   - รายงานสรุปจำนวนหนังสือที่ยืมแต่ละเดือน และผู้ยืมชั้นนำ 10 อันดับแรก
   - เกณฑ์ความสำเร็จ: ต้องสร้างเสร็จภายใน 30 นาที

3. เรียงลำดับชุดผลลัพธ์ขนาดใหญ่:
   - ผลการค้นหา 50,000 เรกคอร์ด เรียงลำดับตามเกณฑ์หลายอย่าง (ความเกี่ยวข้อง วันตีพิมพ์ คะแนนผู้ใช้)
   - เกณฑ์ความสำเร็จ: ต้องแสดงผลหน้าแรก (20 รายการ) ภายใน 2 วินาที

เกณฑ์ประสิทธิภาพโดยรวม:

- เวลาตอบสนองต้องไม่เกิน 5 วินาที แม้ว่าจะต้องจัดการกับข้อมูลขนาดใหญ่
- อัตราข้อผิดพลาด: 0%
- ผลลัพธ์ต้องมีความถูกต้องอย่างแน่นอน ไม่มีการสูญหายของข้อมูล

---

## 1.3 อธิบายเมตริกส์ประสิทธิภาพ

### บทนำ

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

---

### 1. เวลาตอบสนอง (Response Time)

**ความนิยาม:** เวลาตอบสนอง คือระยะเวลาที่วัดจากช่วงเวลาที่ไคลเอนต์ส่งคำขอไปยังเซิร์ฟเวอร์จนกว่าจะได้รับการตอบสนองครบถ้วน

**คุณสมบัติของเวลาตอบสนอง:**

- การวัดเป็นหน่วยมิลลิวินาที (milliseconds) สำหรับส่วนใหญ่ของสถานการณ์
- รวมเวลาการประมวลผลในเซิร์ฟเวอร์ เวลาการถ่ายโอนข้อมูลทางเครือข่าย และเวลาการประมวลผลในไคลเอนต์
- เป็นเมตริกส์ที่สำคัญที่สุดต่อประสบการณ์ผู้ใช้

**เมตริกส์ที่เกี่ยวข้องกับเวลาตอบสนอง:**

**ค่าเฉลี่ย (Mean Response Time)**

- นิยาม: คำนวณจากผลรวมของเวลาตอบสนองทั้งหมดหารด้วยจำนวนคำขอทั้งหมด
- วิธีคำนวณ: Mean = (ผลรวมเวลาตอบสนองทั้งหมด) ÷ (จำนวนคำขอ)
- ข้อจำกัด: ค่าเฉลี่ยสามารถเบี่ยงเบนไปจากความเป็นจริงหากมีค่าผิดปกติสูง (outliers)

**ค่ามัธยฐาน (Median หรือ P50)**

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

**เปอร์เซ็นไทล์ที่ 90 (P90)**

- นิยาม: ค่าที่ 90 เปอร์เซ็นต์ของคำขอมีเวลาตอบสนองน้อยกว่าหรือเท่ากับค่านี้
- บ่งชี้: ประสบการณ์ของผู้ใช้ส่วนใหญ่ (90 เปอร์เซ็นต์)
- ความสำคัญ: เป็นตัวบ่งชี้วิธีการที่ 10 เปอร์เซ็นต์ของผู้ใช้ประสบการณ์ที่ช้า

**เปอร์เซ็นไทล์ที่ 95 (P95)**

- นิยาม: ค่าที่ 95 เปอร์เซ็นต์ของคำขอมีเวลาตอบสนองน้อยกว่าหรือเท่ากับค่านี้
- ความสำคัญ: เป็นมาตรฐาน SLA ทั่วไปที่พบในอุตสาหกรรม
- บ่งชี้: การออกแบบระบบที่สมดุลระหว่างประสิทธิภาพและความเป็นไปได้

**เปอร์เซ็นไทล์ที่ 99 (P99)**

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

**ค่าสูงสุด (Maximum Response Time)**

- นิยาม: เวลาที่นานที่สุดที่บันทึกสำหรับคำขอใดๆ ในการทดสอบ
- ประโยชน์: ช่วยตรวจจับปัญหาขั้นสูง เช่น deadlocks หรือ garbage collection pauses
- ข้อเตือน: ค่านี้สามารถเป็นค่าผิดปกติที่ไม่เกิดซ้ำบ่อยนัก

**เหตุใดเปอร์เซ็นไทล์จึงสำคัญมากกว่าค่าเฉลี่ย:**

_สถานการณ์ที่ 1: ประสิทธิภาพสม่ำเสมอ_

- คำขอ 100 ครั้ง โดยแต่ละครั้งใช้เวลา 100ms
- ค่าเฉลี่ย: 100ms
- P99: 100ms
- ผลลัพธ์: ระบบมีประสิทธิภาพอย่างสม่ำเสมอ

_สถานการณ์ที่ 2: มีคำขอที่ช้าบ้าง_

- คำขอ 99 ครั้ง ใช้เวลา 100ms ต่อครั้ง
- คำขอ 1 ครั้ง ใช้เวลา 10000ms (ช้ามาก)
- ค่าเฉลี่ย: (99 × 100 + 10000) ÷ 100 = 1090ms
- P99: 10000ms
- ผลลัพธ์: แม้ว่าค่าเฉลี่ยเท่ากับ 1090ms แต่ 99 เปอร์เซ็นต์ของผู้ใช้มีประสบการณ์ที่ดี มีเพียง 1 เปอร์เซ็นต์ที่มีประสบการณ์ที่เลวร้าย

**ความสำคัญของการใช้เปอร์เซ็นไทล์:**

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

**มาตรฐานของอุตสาหกรรม:**

- P95 น้อยกว่า 500ms: ระดับดี (ผู้ใช้ส่วนใหญ่มีความสุข)
- P99 น้อยกว่า 1000ms: ระดับยอมรับได้
- P99 มากกว่า 2000ms: ระดับที่ไม่ดี ต้องตรวจสอบและปรับปรุง

---

### 2. จำนวนคำขอที่ประมวลผลได้ต่อหน่วยเวลา (Throughput)

**ความนิยาม:** เมตริกส์นี้วัดจำนวนคำขอหรือธุรกรรมที่ระบบสามารถประมวลผลได้ในหน่วยเวลาที่กำหนด

**หน่วยวัด:**

- RPS (Requests Per Second): จำนวนคำขอต่อวินาที
- TPS (Transactions Per Second): จำนวนธุรกรรมสมบูรณ์ต่อวินาที
- TPM (Transactions Per Minute): จำนวนธุรกรรมต่อนาที

**ความแตกต่างระหว่าง RPS และ TPS:**

- RPS นับเฉพาะการส่งคำขอ ขั้นตอนหนึ่งในกระบวนการ
- TPS วัดกระบวนการธุรกรรมที่สมบูรณ์ ซึ่งอาจประกอบด้วยหลายคำขอ
- ตัวอย่าง: คำขอค้นหาหนังสืออาจนับเป็น 1 RPS แต่อาจจำแนกเป็น 1 TPS

**วิธีการคำนวณ:**

- Throughput = (จำนวนคำขอสำเร็จ) ÷ (ระยะเวลาทั้งหมดเป็นวินาที)
- ตัวอย่าง: หากระบบประมวลผล 10,000 คำขออย่างสำเร็จในเวลา 100 วินาที → Throughput = 100 RPS

**ความสำคัญ:**

- บ่งชี้ความสามารถของระบบในการรองรับปริมาณจราจร
- ใช้เปรียบเทียบประสิทธิภาพระหว่างเวอร์ชันต่างๆ ของระบบ

**ตัวอย่างและการตีความ:**

- ระบบ A: 100 RPS แสดงว่าสามารถประมวลผล 100 คำขอต่อวินาที
- ระบบ B: 1000 RPS แสดงว่าระบบ B มีความสามารถมากกว่า 10 เท่า

**ข้อสังเกต:**

- ภายใต้โหลดต่ำ: ระบบสามารถประมวลผล 1000 RPS
- ภายใต้โหลดสูง: ระบบอาจประมวลผลได้เพียง 500 RPS (หลุดลง 50%)
- ปรากฏการณ์นี้บ่งชี้การมีอยู่ของคอขวดในระบบ

---

### 3. อัตราข้อผิดพลาด (Error Rate)

**ความนิยาม:** เปอร์เซ็นต์ของคำขอที่ไม่สำเร็จหรือส่งกลับข้อผิดพลาดระหว่างการทดสอบ

**วิธีการคำนวณ:**

- Error Rate (%) = (จำนวนคำขอที่ล้มเหลว ÷ จำนวนคำขอทั้งหมด) × 100

**ตัวอย่าง:**

- ทดสอบส่งคำขอ 10,000 ครั้ง
- ล้มเหลว 10 ครั้ง
- Error Rate = (10 ÷ 10,000) × 100 = 0.1%

**ประเภทของข้อผิดพลาด:**

_ข้อผิดพลาด 4xx (Client-side Errors):_

- 400 Bad Request: ไคลเอนต์ส่งคำขอที่ไม่ถูกต้อง
- 401 Unauthorized: การยืนยันตัวตนล้มเหลว
- 403 Forbidden: ผู้ใช้ไม่มีสิทธิ์การเข้าถึง
- 404 Not Found: ไม่พบทรัพยากร
- ความหมาย: ความผิดพลาดจากฝั่งไคลเอนต์ ระบบตอบสนองถูกต้องโดยปฏิเสธคำขอ

_ข้อผิดพลาด 5xx (Server-side Errors):_

- 500 Internal Server Error: เกิดข้อผิดพลาดที่ไม่คาดคิดในเซิร์ฟเวอร์
- 502 Bad Gateway: เซิร์ฟเวอร์ gateway ได้รับการตอบสนองที่ไม่ถูกต้องจากเซิร์ฟเวอร์อื่น
- 503 Service Unavailable: เซิร์ฟเวอร์ไม่พร้อมให้บริการ
- ความหมาย: ข้อผิดพลาดมาจากฝั่งเซิร์ฟเวอร์ ปัญหาเลวร้ายกว่า

**ระดับที่ยอมรับได้:**

- น้อยกว่า 0.1%: ระดับยอดเยี่ยม (ปกติสำหรับระบบวิกฤต)
- 0.1 - 1%: ระดับยอมรับได้ (ขึ้นอยู่กับข้อตกลง SLA)
- มากกว่า 1%: ระดับที่ไม่ดี ต้องตรวจสอบสาเหตุ

**ความสำคัญ:**

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

---

### 4. การใช้ทรัพยากร (Resource Utilization)

**ความนิยาม:** วัดปริมาณทรัพยากรคอมพิวเตอร์ (CPU, หน่วยความจำ, เครือข่าย) ที่ใช้โดยระบบในระหว่างการทดสอบ

**การใช้ CPU (Central Processing Unit):**

- หน่วยวัด: เปอร์เซ็นต์ของความสามารถของโปรเซสเซอร์ที่ใช้งาน
- 0-40%: ยังมีพื้นที่เพียงพอสำหรับการขยายระบบ
- 40-70%: ระดับปานกลาง การใช้งานระบบอยู่ในเกณฑ์ปกติ
- 70-85%: เข้าใกล้ขีดจำกัด ความเสี่ยงต่อการชะลอตัวของระบบ
- มากกว่า 85%: พื้นที่เสี่ยง ต้องเตรียมการปรับปรุงในไม่ช้า

**การใช้หน่วยความจำ (Memory):**

- หน่วยวัด: เปอร์เซ็นต์ของหน่วยความจำที่ติดตั้งที่ใช้งาน
- 0-60%: ระดับปกติ ยังมีพื้นที่เพียงพอ
- 60-80%: ต้องติดตามการรั่วของหน่วยความจำ (memory leaks)
- มากกว่า 90%: ความเสี่ยงต่อการขัดข้องของระบบ

**หลุดรั่วหน่วยความจำ (Memory Leaks):**

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

**ฐานข้อมูล (Database Metrics):**

- เวลาการดำเนินการสอบถาม (Query Execution Time): เวลาที่เซิร์ฟเวอร์ฐานข้อมูลใช้เพื่อประมวลผลและส่งคืนผลลัพธ์
- การใช้สระการเชื่อมต่อ (Connection Pool Usage): เปอร์เซ็นต์ของการเชื่อมต่อที่ถูกใช้
- การสอบถามที่ช้า (Slow Queries): การสอบถามที่ใช้เวลามากกว่าเกณฑ์ที่กำหนด (ปกติ > 1 วินาที)

**ความสำคัญของการวัดการใช้ทรัพยากร:**

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

---

### 5. ผู้ใช้พร้อมกัน (Virtual Users - VUs)

**ความนิยาม:** จำนวนผู้ใช้จำลองที่ใช้ระบบพร้อมกันในการทดสอบ

**ความแตกต่างระหว่างผู้ใช้จำลองและผู้ใช้จริง:**

- ผู้ใช้จำลอง (VU): ผู้ใช้ที่สร้างขึ้นโดยเครื่องมือทดสอบ โดยจำลองพฤติกรรมของผู้ใช้จริง
- ผู้ใช้จริง: ผู้ใช้ที่เข้าถึงระบบจริงในสภาพแวดล้อมการผลิต
- ความสัมพันธ์: 1 VU ไม่เสมอเท่ากับ 1 ผู้ใช้จริง เนื่องจากขึ้นอยู่กับระยะเวลาในการทำรายการ

**การกำหนดจำนวน VU:**

- ระบุจำนวนผู้ใช้ที่คาดว่าจะใช้ระบบพร้อมกันในเวลาสูงสุด
- ตัวอย่าง: หากห้องสมุดคาดว่ามีผู้ใช้ 100 คนพร้อมกันในช่วงเวลาสูงสุด ควรตั้งค่า VU เป็น 100

**การเพิ่มจำนวน VU:**

- ทำให้เข้าใจปัญหาเมื่อจำนวนผู้ใช้เพิ่มขึ้น
- ช่วยการ stress testing ในการค้นหาจุดสูงสุด

---

### การตีความผลการทดสอบรวมกัน

เมตริกส์ทั้งห้าข้างต้นควรพิจารณารวมกัน:

- ถ้า P95 response time นั้นดี แต่ error rate สูง: อาจบ่งชี้ปัญหาในการออกแบบ
- ถ้า throughput ต่ำ แต่ CPU usage สูง: บ่งชี้ว่าโค้ดไม่มีประสิทธิภาพ
- ถ้าการใช้หน่วยความจำเพิ่มขึ้นตามเวลา: บ่งชี้ถึงหลุดรั่ว

---

## 1.4 กระบวนการทดสอบประสิทธิภาพ

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

---

### ขั้นตอนที่ 1: ระบุและวิเคราะห์สถานการณ์การทดสอบ

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

**ขั้นตอนการทำงาน:**

1. ศึกษา User Journey (เส้นทางการใช้งานของผู้ใช้):
   - ระบุชุดหลักของการดำเนินการ (Key Actions) ที่ผู้ใช้ทำบ่อยที่สุด
   - เข้าใจว่าการไหลของข้อมูลเป็นอย่างไร เช่น จากการค้นหา → การดู → การยืม
   - สร้างแผนผังของสถานการณ์ User Journey ที่สำคัญ

2. วิเคราะห์ความถี่ของการใช้งาน:
   - ฟีเจอร์ใดที่มีการใช้งานมากที่สุด (ปกติจะอยู่ที่ 50-80% ของจราจรทั้งหมด)
   - ฟีเจอร์ใดที่มีการใช้งานน้อยแต่สำคัญ (เช่น การทำธุรกรรมการชำระเงิน)
   - ไหลการใช้งานแบบใด

3. ฤษี่ช่วงเวลาและโหลดสูงสุด:
   - ระบุว่าช่วงเวลาใดในวัน สัปดาห์ หรือปี ที่มีจำนวนผู้ใช้เยอะสุด
   - ตัวอย่าง: วันธรรมชาติ วันหยุด หรือช่วงเปิดเทอม
   - บันทึกว่าจำนวนผู้ใช้เพิ่มขึ้นเท่าไหร่เมื่อเปรียบเทียบกับวันธรรมชาติ

**ตัวอย่าง: ระบบจัดการห้องสมุด**

```
สถานการณ์การใช้งานที่พบบ่อย:
- 50% ของจราจร: ค้นหาหนังสือ (ฟีเจอร์ที่มีการใช้บ่อยที่สุด)
- 30% ของจราจร: ยืมหนังสือ (ฟีเจอร์ที่สำคัญสำหรับธุรกิจ)
- 15% ของจราจร: คืนหนังสือ
- 5% ของจราจร: ดูประวัติการยืม และจัดการสมาชิก

เวลาสูงสุด:
- ช่วงเปิดเทอม (เพิ่มขึ้น 300% เมื่อเทียบกับวันธรรมชาติ)
- ช่วงสิ้นสัปดาห์ (เพิ่มขึ้น 150%)
- ช่วงเที่ยงวัน (เพิ่มขึ้น 200% เมื่อเทียบกับช่วงเช้า)
```

---

### ขั้นตอนที่ 2: กำหนดเกณฑ์ประสิทธิภาพและข้อเสนอ SLA

**วัตถุประสงค์:** ก่อนการทดสอบ ต้องมีความชัดเจนว่าระบบต้องทำงานได้ 'ดี' แค่ไหน เพื่อให้สามารถใช้เป็นเกณฑ์ผ่าน/ล้มเหลว

**ความนิยาม SLA:** Service Level Agreement คือข้อตกลงระหว่างผู้ให้บริการกับลูกค้า ที่ระบุระดับของการบริการที่ผู้ให้บริการจะรับผิดชอบ

**ขั้นตอนการกำหนด SLA:**

1. เก็บรวบรวมข้อมูลจากผู้มีส่วนได้ส่วนเสีย (Stakeholders):
   - ผู้บริหาร (Business): ต้องการความพึงพอใจของลูกค้า และต้นทุนต่ำ
   - ผู้ใช้ (Users): ต้องการความเร็ว และปลอดภัย
   - ทีมเทคนิก (Technical Team): ต้องการความปลอดภัย และเสถียรภาพ

2. กำหนดเกณฑ์ประสิทธิภาพเฉพาะเจาะจง (SMART Goals):
   - ระบุเวลาตอบสนองสูงสุดที่ยอมรับได้ (เช่น P95 < 500ms)
   - ระบุอัตราข้อผิดพลาดที่ยอมรับได้ (เช่น < 0.1%)
   - ระบุจำนวนผู้ใช้สูงสุดที่ต้องรองรับ (เช่น 10,000 concurrent users)
   - ระบุความพร้อมใช้งาน (Availability) เช่น 99.5% uptime

3. ตรวจสอบความเป็นไปได้:
   - เปรียบเทียบกับเกณฑ์อุตสาหกรรม
   - พิจารณาวิธีการจัดหาทรัพยากร
   - ตรวจสอบว่าหรือจำเป็นต้องปรับเปลี่ยนเกณฑ์

**ตัวอย่าง SLA สำหรับระบบห้องสมุด**

```
ความต้องการประสิทธิภาพที่เฉพาะเจาะจง:

API ค้นหาหนังสือ:
- Availability: 99.5% (สามารถพัง ได้ไม่เกิน 3.6 ชั่วโมงต่อเดือน)
- Response Time P95: 500ms (95% ของคำขอตอบในเวลา <= 500ms)
- Response Time P99: 1000ms (99% ของคำขอตอบในเวลา <= 1000ms)
- Error Rate: < 0.1% (ล้มเหลวไม่เกิน 1 ครั้งต่อ 1000 คำขอ)
- Max Concurrent Users: 5000 คน

API ยืมหนังสือ (สำคัญ เพราะเกี่ยวข้องกับธุรกิจ):
- Availability: 99.95% (สามารถพัง ได้ไม่เกิน 1.8 ชั่วโมงต่อเดือน)
- Response Time P95: 1000ms
- Response Time P99: 2000ms
- Error Rate: < 0.05%
- Max Concurrent Users: 2000 คน
```

---

### ขั้นตอนที่ 3: ออกแบบสถานการณ์การทดสอบโดยละเอียด

**วัตถุประสงค์:** สร้างแบบแผนการทดสอบที่ชัดเจน ซึ่งสามารถนำไปใช้งานของผู้อื่นหรือซ้ำได้ (Repeatable)

**ส่วนประกอบที่สำคัญของการออกแบบ:**

1. **ข้อมูลการทดสอบพื้นฐาน**
   - ชื่อการทดสอบ (Test Name): ต้องอธิบายสิ่งที่ทดสอบ เช่น "Performance Test - Normal Load Scenario"
   - ประเภทของการทดสอบ (Test Type): Load, Stress, Spike, Endurance, Volume
   - วัตถุประสงค์: อะไรคือเป้าหมายของการทดสอบนี้

2. **กำหนดค่าโหลด (Load Configuration)**
   - จำนวนผู้ใช้ขั้นต้น (Initial VUs): เช่น 10 คน
   - จำนวนผู้ใช้สูงสุด (Peak VUs): เช่น 500 คน
   - ระยะเวลารวม (Total Duration): เช่น 30 นาที
   - ช่วงเวลา (Ramp-up/Ramp-down): กี่นาทีที่ใช้เพื่อเพิ่ม/ลดจำนวนผู้ใช้

3. **ข้อมูลการกระจัดกระจาย (Distribution)**
   - จำนวนผู้ใช้สำหรับแต่ละรูปแบบการใช้งาน
   - ตัวอย่าง: 50% ค้นหา, 30% ยืม, 20% คืน

4. **เกณฑ์ความสำเร็จ (Success Criteria)**
   - ต้องเป็นไปตามเกณฑ์ SLA ที่กำหนด
   - อัตราข้อผิดพลาดต้องน้อยกว่า 0.1%
   - ไม่มีการเพิ่มขึ้นของหน่วยความจำ (No memory growth)

**ตัวอย่าง: การออกแบบสถานการณ์การทดสอบโหลด**

```
ชื่อ: "Performance Test - Normal Business Day Load"
ประเภท: Load Testing
วัตถุประสงค์: ตรวจสอบระบบสามารถรองรับการใช้งานในวันธรรมชาติ

โครงสร้างการทดสอบ:
- ขั้น 1 (0-5 นาที): เพิ่มผู้ใช้จาก 0 เป็น 50 คน (Warm-up)
- ขั้น 2 (5-25 นาที): ปล่อยให้อยู่ที่ 50 คน (Steady state)
- ขั้น 3 (25-30 นาที): ลดผู้ใช้จากา50 เป็น 0 (Cool-down)

การกระจายการใช้งาน:
- 50% ค้นหาหนังสือ
- 30% ยืมหนังสือ
- 15% คืนหนังสือ
- 5% ดูประวัติ

เกณฑ์ความสำเร็จ:
- P95 Response Time < 500ms
- Error Rate < 0.1%
- CPU Usage < 70%
- Memory Usage < 80%
```

---

### ขั้นตอนที่ 4: ดำเนินการทดสอบและการจัดเก็บข้อมูล

**วัตถุประสงค์:** ดำเนินการทดสอบตามแบบแผนและรวบรวมข้อมูลโดยละเอียด

**ขั้นตอนการปฏิบัติการ:**

1. **ตรวจสอบสภาพแวดล้อมการทดสอบ**
   - ตรวจสอบว่าโปรแกรมประเมินมีพื้นที่ว่างเพียงพอ
   - ตรวจสอบการเชื่อมต่อเครือข่าย
   - ตรวจสอบว่าระบบเป้าหมายเป็นเสถียรและพร้อม

2. **ติดตั้งการติดตามและบันทึก (Monitoring and Logging)**
   - ไฟล์บันทึก (Log files): ตั้งค่าเพื่อบันทึกข้อผิดพลาด คำเตือน และเหตุการณ์พิเศษ
   - เครื่องมือจัดตัดสินใจ: เช่น Prometheus, Grafana, DataDog
   - ตรวจสอบประสิทธิภาพฐานข้อมูล: ตรวจสอบการแบ่ง Lock, การรวบรวมสถิติ

3. **เริ่มการทดสอบ**
   - บันทึกเวลาเริ่มต้น
   - เริ่มการทดสอบตามแบบแผนที่ออกแบบไว้
   - สังเกตผลลัพธ์ที่แสดง

4. **ตรวจสอบและบันทึกระหว่างการทดสอบ**
   - ตรวจสอบอัตราข้อผิดพลาด: ถ้ามีจำนวนมากเพิ่มขึ้น อาจบ่งชี้ปัญหา
   - ตรวจสอบเวลาตอบสนอง: สัง‌เกตว่ามีแนวโน้มเพิ่มขึ้นหรือบ่งชี้ปัญหา
   - ตรวจสอบการใช้ทรัพยากร:
     - การใช้ CPU: ควรค่อนข้างคงที่
     - การใช้หน่วยความจำ: ไม่ควรเพิ่มขึ้นอย่างต่อเนื่อง (ระบุ Memory Leak)
     - เครือข่าย: ตรวจสอบการป่องกัน (Bandwidth) ใช้เพียง 50-70% ของสมรรถนะสูงสุด
   - ตรวจสอบบันทึก:
     - มีข้อผิดพลาด SQL หรือไม่
     - มีข้อยกเว้น (Exception) ที่คาดการไม่ได้หรือไม่
     - มีคำเตือนสำคัญหรือไม่

---

### ขั้นตอนที่ 5: วิเคราะห์ผลลัพธ์ และการเทียบเคียง

**วัตถุประสงค์:** แปลงข้อมูลดิบเป็นข้อมูลที่มีความหมาย และนำมาตัดสินใจ

**ขั้นตอนการวิเคราะห์:**

1. **เปรียบเทียบกับเกณฑ์ SLA**
   - ตัวอย่าง:

     ```
     เกณฑ์: P95 Response Time < 500ms
     ผลลัพธ์: P95 = 480ms
     ผลการประเมิน: ผ่าน (ยอมรับได้)

     เกณฑ์: Error Rate < 0.1%
     ผลลัพธ์: Error Rate = 0.15%
     ผลการประเมิน: ล้มเหลว (ต้องสืบสวน)
     ```

2. **ระบุคอขวด (Bottlenecks)**
   - สัง‌เกตว่าตรงไหนคืนผลช้า:
     - API ค้นหา? → อาจเป็นปัญหาฐานข้อมูล หรือตัวกรอง (Filter)
     - API ยืม? → อาจเป็นปัญหาการตรวจสอบธุรกิจ (Business Logic)
     - ฐานข้อมูล? → ตรวจสอบสืบสวน (Query Plan) และ index
   - ตัวอย่าง:
     ```
     สังเกต: API ค้นหาใช้เวลา 2 วินาที (แต่คำคุณสมบัติคือ 500ms)
     สืบสวน: ดูบันทึก SQL ค้นหาการสอบถามที่ช้า
     ผลการค้นหา: SELECT * FROM books WHERE title LIKE '%search%'
                 (ไม่มี INDEX บนคอลัมน์ title)
     สาเหตุรากฐาน: ขาดการอ้างอิง INDEX บนตาราหลัก
     คำแนะนำ: เพิ่ม INDEX บนคอลัมน์ title
     ```

3. **ตรวจสอบการใช้ทรัพยากร**
   - ประเมินว่ากำหนดค่า CPU เพียงพอหรือไม่
   - ประเมินว่าหน่วยความจำ เพียงพอหรือมีการรั่ว
   - ตัวอย่าง:
     ```
     CPU Usage: 45% (เป็นสุข เหลือพื้นที่สำหรับการเติบโต)
     Memory Usage: 65% (ยอมรับได้ แต่ต้องจับตาดู)
     Memory Trend: ค่อยๆ เพิ่มขึ้นจาก 55% เป็น 65% (อาจมี Memory Leak)
     Database Connections: 85/100 (เข้าใกล้ขีดจำกัด อาจเป็นปัญหา)
     ```

4. **วิเคราะห์แนวโน้ม**
   - เปรียบเทียบกับการทดสอบครั้งก่อน (ถ้ามี)
   - ประเมินว่าประสิทธิภาพดีขึ้น แย่ลง หรือเสมอ

---

### ขั้นตอนที่ 6: รายงานผลการทดสอบและข้อแนะนำ

**วัตถุประสงค์:** สื่อสารผลลัพธ์ให้กับผู้มีส่วนได้ส่วนเสีย และให้ข้อแนะนำในการปรับปรุง

**โครงสร้างรายงาน:**

1. **สรุปสำหรับผู้บริหาร (Executive Summary)**
   - ประเมินโดยรวม: ระบบ ผ่าน/ล้มเหลว SLA หรือไม่
   - ปัญหาหลัก: ระบุปัญหาที่สำคัญที่สุด
   - ข้อแนะนำด่วน: ต้องจัดการเรื่องอะไรก่อนอื่น

2. **การกำหนดค่าการทดสอบ (Test Configuration)**
   - ระบุการทดสอบที่ดำเนินการ
   - วันที่ดำเนินการ
   - สภาพแวดล้อม (Production-like, Staging, etc.)

3. **ผลลัพธ์เชิงตัวเลข (Quantitative Results)**
   - ตาราแสดงตัวเลขสำคัญ:
     ```
     | เมตริกส์ | เกณฑ์ | ผลลัพธ์ | สถานะ |
     |---------|------|--------|-------|
     | P95 Response Time | < 500ms | 480ms | ผ่าน |
     | P99 Response Time | < 1000ms | 950ms | ผ่าน |
     | Error Rate | < 0.1% | 0.15% | ล้มเหลว |
     | Throughput | > 100 RPS | 120 RPS | ผ่าน |
     ```
   - กราฟแสดงแนวโน้ม:
     - Time vs Response Time
     - Time vs Error Rate
     - Time vs Resource Usage

4. **คำค้นหาคอขวด (Bottleneck Analysis)**
   - ระบุส่วนที่สำคัญที่สุดที่ต้องปรับปรุง
   - ให้ข้อมูลเพิ่มเติมว่าปัญหาอยู่ที่ไหน

5. **ประเด็นและข้อแนะนำ (Issues and Recommendations)**
   - ประเด็น 1: Error Rate สูง
     - สาเหตุ: API บางตัวไม่จัดการ Exception อย่างถูกต้อง
     - ลำดับความสำคัญ: สูง (affect SLA)
     - ข้อแนะนำ: เปิด error handling ในเนื้อหา API
   - ประเด็น 2: Memory Leak ที่อาจเกิดขึ้น
     - สาเหตุ: ความเป็นไปได้มีการรั่วของทรัพยากร
     - ลำดับความสำคัญ: ปานกลาง (อาจเป็นปัญหาในระยะยาว)
     - ข้อแนะนำ: ทำการ profiling และตรวจจับ memory leak

6. **ข้อมูลเพิ่มเติม**
   - บันทึกข้อผิดพลาด (Log files)
   - กราฟการให้บริการของระบบ
   - ข้อมูลเก็บถาวร (Archive) สำหรับการนำหน้า

---

### การวนซ้ำ (Iterative Improvement)

**ขั้นตอนหลังจากการทดสอบ:**

1. **ปรับปรุงและอัปเดต**
   - ทีมพัฒนาแก้ไขไม่ได้แก้ไขตามข้อแนะนำ
   - ติดตั้งการเปลี่ยนแปลง

2. **ทดสอบซ้ำ**
   - ทำการทดสอบอีกครั้งด้วยการกำหนดค่าเดียวกันเพื่อเปรียบเทียบ
   - บันทึกการปรับปรุง

3. **ตรวจสอบการเทียบเคียง**
   - ตรวจสอบว่าหน่วยความจำลดลง
   - ตรวจสอบว่า Error Rate ลดลง
   - รายงานผลการปรับปรุง

---

---

# ส่วนที่ 2: บทนำเกี่ยวกับ k6 และเครื่องมือเว็บ

---

## 2.1 k6 คืออะไร

**k6** เป็นเครื่องมือทดสอบประสิทธิภาพและการทดสอบโหลด (Load Testing Tool) ที่มีลักษณะสมัยใหม่และเป็นโอเพนซอร์ส ได้รับการออกแบบมาเพื่อให้นักพัฒนาและวิศวกรทดสอบสามารถทำการทดสอบประสิทธิภาพได้อย่างง่ายดายและมีประสิทธิภาพสูง

**เหตุผลที่ควรใช้ k6:**

- **ฟรีและเป็นโอเพนซอร์ส** - ไม่มีค่าใบอนุญาต สามารถศึกษา ปรับแต่ง และขยายได้
- **ง่ายต่อการใช้งาน** - สคริปต์การทดสอบเขียนในภาษา JavaScript ซึ่งนักพัฒนาส่วนใหญ่คุ้นเคยแล้ว
- **สมัยใหม่สำหรับสภาพแวดล้อมคลาวด์** - ออกแบบมาโดยคำนึงถึงแอปพลิเคชันเว็บสมัยใหม่ที่ใช้สถาปัตยกรรมไมโครเซอร์วิส
- **ทรงพลัง** - สามารถสร้างโหลดที่มากมายหลายพันผู้ใช้พร้อมกันบนเครื่องคอมพิวเตอร์เครื่องเดียว
- **เป็นมิตรกับนักพัฒนา** - มีไวยากรณ์ที่ชัดเจน เข้าใจง่าย และมีตัวอย่าง API ที่สอดคล้องกับมาตรฐานอุตสาหกรรม
- **บูรณาการกับระบบอัตโนมัติ** - สามารถผนวกเข้ากับ CI/CD Pipeline ได้อย่างราบรื่น ทำให้สามารถรันการทดสอบประสิทธิภาพในการทำงานอัตโนมัติได้

---

## 2.2 การทดสอบ k6 พื้นฐาน

โครงสร้างพื้นฐานของสคริปต์การทดสอบ k6 ประกอบด้วยส่วนสำคัญดังต่อไปนี้:

**ตัวอย่างโค้ด:**

```javascript
import http from "k6/http";
import { check } from "k6";

// การกำหนดค่าการทดสอบ
export const options = {
  vus: 10, // จำนวนผู้ใช้จำลอง 10 คน
  duration: "30s", // ระยะเวลาการทดสอบ 30 วินาที
};

// ฟังก์ชันหลัก - จะรันสำหรับแต่ละผู้ใช้จำลอง
export default function () {
  // ส่งคำขอ HTTP GET ไปยัง API
  const res = http.get("http://localhost/api/books");

  // ตรวจสอบการตอบสนอง
  check(res, {
    "status 200": (r) => r.status === 200,
    "response time < 500ms": (r) => r.timings.duration < 500,
  });
}
```

**คำอธิบายส่วนประกอบ:**

- **import** - นำเข้าฟังก์ชันจากไลบรารี k6 สำหรับการส่งคำขอ HTTP และการตรวจสอบผลลัพธ์
- **options** - กำหนดค่าการทดสอบเช่น จำนวนผู้ใช้จำลอง (vus) และระยะเวลาการทดสอบ (duration)
- **default function** - ฟังก์ชันหลักที่จะรันซ้ำ ๆ สำหรับแต่ละผู้ใช้จำลองตลอดระยะเวลาการทดสอบ
- **http.get()** - ส่งคำขอ HTTP GET ไปยัง URL ที่ระบุ
- **check()** - ตรวจสอบว่าการตอบสนองตรงตามเงื่อนไขที่กำหนด หากล้มเหลว k6 จะนับเป็นข้อบกพร่องและบันทึกไว้

---

## 2.3 รูปแบบโหลด (Load Patterns) ใน k6

k6 จัดเตรียมรูปแบบโหลดหลากหลายเพื่อจำลองสถานการณ์ต่าง ๆ:

### 1. โหลดคงที่ (Constant Load)

กำหนดจำนวนผู้ใช้คงที่ตลอดระยะเวลาการทดสอบ:

```javascript
export const options = {
  vus: 50, // จำนวนผู้ใช้คงที่ 50 คน
  duration: "5m", // ทั้งหมด 5 นาที
};
```

**ใช้สำหรับ:** การทดสอบโหลดแบบปกติ เพื่อประเมินประสิทธิภาพภายใต้สภาวะการใช้งานระหว่างวัน

---

### 2. โหลดเพิ่มเรื่อยๆ (Ramping Load)

เพิ่มจำนวนผู้ใช้ทีละน้อยตามระยะเวลาที่กำหนด เพื่อจำลองการเพิ่มประมาณของผู้ใช้ในช่วงเช้า:

```javascript
export const options = {
  stages: [
    { duration: "1m", target: 20 }, // ขั้นที่ 1: เพิ่มจาก 0 เป็น 20 คน ใน 1 นาที
    { duration: "3m", target: 20 }, // ขั้นที่ 2: คงที่ที่ 20 คน ใน 3 นาที
    { duration: "1m", target: 0 }, // ขั้นที่ 3: ลดจาก 20 เป็น 0 คน ใน 1 นาที
  ],
};
```

**ใช้สำหรับ:** การทดสอบประสิทธิภาพแบบค่อยเป็นค่อยไป เช่น การจำลองจำนวนผู้ใช้ที่เพิ่มขึ้นอย่างค่อยเป็นค่อยไปในช่วงเช้า แล้วค่อย ๆ ลดจำนวนลง

---

### 3. การทดสอบจุดสูงสุด (Spike Testing)

เพิ่มโหลดอย่างกะทันหันจากปกติเป็นจำนวนมากในช่วงสั้น ๆ เพื่อจำลองสถานการณ์ที่ผู้ใช้จำนวนมากเข้าพร้อม ๆ กัน:

```javascript
export const options = {
  stages: [
    { duration: "1m", target: 100 }, // โหลดปกติ: 100 คน
    { duration: "10s", target: 500 }, // จุดสูงสุด: เพิ่มเป็น 500 คนอย่างทันที
    { duration: "1m", target: 100 }, // กลับสู่ปกติ: ลดเป็น 100 คน
  ],
};
```

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

---

## 2.4 เกณฑ์การผ่าน (Thresholds)

เกณฑ์การผ่านเป็นตัวกำหนดว่าการทดสอบจะผ่านหรือล้มเหลวตามเงื่อนไขที่กำหนดไว้ ช่วยให้การประเมินผลเป็นไปโดยอัตโนมัติ:

**ตัวอย่างการกำหนดเกณฑ์:**

```javascript
export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    // เปอร์เซ็นไทล์ที่ 95 ของเวลาตอบสนองต้องน้อยกว่า 500 มิลลิวินาที
    http_req_duration: ["p(95)<500"],

    // อัตราข้อผิดพลาดต้องน้อยกว่า 1 เปอร์เซ็นต์
    http_req_failed: ["rate<0.01"],

    // เปอร์เซ็นไทล์ที่ 99 ต้องน้อยกว่า 1000 มิลลิวินาที
    http_req_duration: ["p(99)<1000"],
  },
};
```

**คำอธิบายเกณฑ์ต่าง ๆ:**

- **p(95)<500** - หมายความว่า 95 เปอร์เซ็นต์ของคำขอต้องได้รับการตอบสนองภายในเวลา 500 มิลลิวินาที หากมีคำขอเกิน 5% ที่ช้ากว่านี้ การทดสอบจะถือว่าล้มเหลว
- **rate<0.01** - หมายความว่าอัตราข้อผิดพลาดต้องไม่เกิน 1 เปอร์เซ็นต์ของคำขอทั้งหมด
- **p(99)<1000** - หมายความว่า 99 เปอร์เซ็นต์ของคำขอต้องได้รับการตอบสนองภายในเวลา 1000 มิลลิวินาที

**ประโยชน์ของเกณฑ์การผ่าน:**

- ให้ความชัดเจนในการประเมินว่าการทดสอบสำเร็จหรือไม่
- สามารถอัตโนมัติการรายงานผลการทดสอบและการตัดสินใจ
- ใช้ใน CI/CD Pipeline เพื่อตัดสินใจว่าจะอนุมัติ Pull Request หรือป้องกันการรีลีสโค้ดที่ไม่ตรงตามมาตรฐาน

---

---

# ส่วนที่ 3: การทดสอบการเปลี่ยนแปลงภาพ [ทางเลือก]

---

## 3.1 การทดสอบการเปลี่ยนแปลงภาพคืออะไร?

**นิยาม:** ตรวจจับโดยอัตโนมัติ **การเปลี่ยนแปลงภาพ** ใน UI

**เมื่อใช้:**

- การเปลี่ยน CSS
- การอัปเดตเลย์เอาต์
- การทดสอบการออกแบบแบบตอบสนอง
- การเปลี่ยนแปลงส่วนประกอบ UI

**ตัวอย่าง:**

```
ภาพหน้าจอพื้นฐาน: ถูกต้อง
[ปุ่มลักษณ์ปกติ]

ภาพหน้าจอหลังการเปลี่ยน CSS: ไม่ถูกต้อง
[ปุ่มดูขัด ดูเกะกะ หรือผิดปกติ]

การเปรียบเทียบโดยอัตโนมัติ: "พบความแตกต่าง!"
=> ตรวจจับการเปลี่ยนแปลง UI ที่ไม่ตั้งใจ
```

---

## 3.2 เครื่องมือ: ภาพหน้าจอ Playwright

```javascript
import { test, expect } from "@playwright/test";

test("book details page visual", async ({ page }) => {
  // นำทาง
  await page.goto("http://localhost/book_view.php?id=1");

  // บันทึกภาพหน้าจอ
  await expect(page).toHaveScreenshot("book-details.png");
  // หากพื้นฐานไม่ตรงกับปัจจุบัน → ล้มเหลว
});
```

---

## 3.3 การทดสอบมุมมองหลาย

```javascript
// ทดสอบบนขนาดจอหลาย
const devices = ["desktop", "tablet", "mobile"];

for (const device of devices) {
  await page.setViewportSize({
    width: viewportSizes[device].width,
    height: viewportSizes[device].height,
  });

  await expect(page).toHaveScreenshot(`book-${device}.png`);
}
```

---

---

# สรุป & ประเด็นหลัก

| แนวคิด                  | จำไว้                                               |
| ----------------------- | --------------------------------------------------- |
| **การทดสอบประสิทธิภาพ** | "ระบบทำงานยอมรับได้ภายใต้โหลดหรือไม่?"              |
| **5 ประเภท**            | โหลด ความเครียด จุดสูงสุด ความทนทาน ปริมาณ          |
| **เมตริกหลัก**          | เวลาตอบสนอง (P95/P99) ปริมาณการส่ง อัตราข้อผิดพลาด  |
| **เครื่องมือ k6**       | ภาษาจาวาสคริปต์ สมัยใหม่ ฟรี                        |
| **การวิเคราะห์**        | เทียบกับ SLA ระบุคอขวด รายงานผลการค้นหา             |
| **การทดสอบภาพ**         | ทางเลือก สำหรับการจับการเปลี่ยนแปลง UI โดยไม่ตั้งใจ |

---

# ต่อไป: ปฏิบัติการสัปดาห์ที่ 13

ในเซสชันปฏิบัติการ คุณจะ:

1. สร้างสคริปต์การทดสอบโหลด k6
2. ดำเนินการทดสอบกับระบบจัดการห้องสมุด
3. วิเคราะห์เมตริกส์ (เวลาตอบสนอง ปริมาณการส่ง อัตราข้อผิดพลาด)
4. สร้างรายงานการทดสอบประสิทธิภาพ
5. (ทางเลือก) สร้างฐานข้อมูลอ้างอิงของภาพสำหรับการเปลี่ยนแปลงภาพ

---