SF332

การทดสอบและประกันคุณภาพซอฟต์แวร์
Software Testing and Quality Assurance

Week 9
Performance Testing

SF332 Software Testing and Quality Assurance 1

 Agenda
Performance Efficiency
(ISO/IEC25010:2011)

Type of Performance Testing

Performance Testing Process

Performance Testing Tools

SF332 Software Testing and Quality Assurance 2

 Performance Problem
PPTV 28 มี.ค. 63 - นายลวรณ แสงสนิท ผู้อานวยการสานักงาน
มติชน 27 ก.ค. 64 -ชาวสงขลาบ่นอุบ
เศรษฐกิจการคลัง เผยประชาชนเข้าลงทะเบียนรับเงินเยียวยา 5,000 บาท
ระบบจองซิโนฟาร์มของ อบจ. สงขลา ล่ม
เป็นจานวนมากเกินกว่าระบบรองรับได้ จาเป็นต้องปิดระบบชั่วคราว คาด
ตั้งแต่เปิดจอง ซึ่ง อบจ. สงขลา ได้รับการ
เปิดอีกครั้งเที่ยงคืนนี้
จัดสรรวัคซีนทางเลือกซิโนฟาร์มจากราช
วิทยาลัยจุฬาภรณ์จานวน 18,830 คน

Nation 1 ม.ค. 65 -สำนักงำนสลำกกิน

แบ่งรัฐบำล เปิ ดลงทะเบียนผูค้ ำ้ ลอตเตอรี่
รำยย่อยรอบใหม่ แก้ไขปั ญหำสลำกกิน
แบ่งเกินรำคำ 80 บำท เริม่ วันนี ้ (1 ม.ค.)
แต่ระบบล่ม ลงทะเบียนไม่ได้ คนแห่โวย
หน้ำเพจเฟซบุ๊กกองสลำกฯ แซะระบบจะ
ล่มยำวไป 31 วันหรือไม่?

SF332 Software Testing and Quality Assurance 3

 Performance Efficiency (ISO/IEC25010:2011)
Non-Functional Performance relative to the amount of resources
Testing Performance used under stated conditions
efficiency คุณภาพที่เกี่ยวข้องกับจานวน/ปริมาณของทรัพยากรที่ใช้ภายใต้
เงื่อนไขที่กาหนด

Time Resource
Capacity
behavior Utilization

Degree to which the response and
processing times and throughput rates
of a product or system, when performing
its functions, meet requirements
ระยะเวลาที่ใช้ในการตอบโต้กับผู้ใช้และที่ใช้ใน
การประมวลผล
Degree to which the amounts and
types of resources used by a
product or system, when performing
its functions, meet requirements
ปริมาณและประเภทของทรัพยากรที่ใช้โดย
ผลิตภัณฑ์หรือระบบเมื่อทาหน้าที่ตาม
ข้อกาหนด
Degree to which the maximum limits of a product or system
parameter meet requirements (number of item that can be
stored, number of concurrent users, communication bandwidth,
throughput of transactions, size of database)
ขีดจากัดสูงสุดของพารามิเตอร์/ตัวแปรของผลิตภัณฑ์หรือระบบตรงกับความ
ต้องการ (จานวนรายการที่สามารถจัดเก็บได้ , จานวนผู้ใช้งานที่สามารถใช้
พร้อมกัน , ขนาดของแบนด์วิดท์ที่ใช้ในการรับส่งข้อมูล , ขนาดของฐานข้อมูล)

SF332 Software Testing and Quality Assurance 4

 Performance Testing - Architecture
Users Internet Firewall Load Balancer Web Servers Application Database
Servers Servers
Network

Monitoring ส่วนต่างๆ ของระบบด้วยเสมอด้วย เช่น

•การใช้งาน CPU
•การใช้งาน Memory
•การใช้งาน Disk I/O

SF332 Software Testing and Quality Assurance 5

 Agenda
Performance Efficiency
(ISO/IEC25010:2011)

Type of Performance Testing

Performance Testing Process

Performance Testing Tools

SF332 Software Testing and Quality Assurance 6

 Type of Performance Testing
Performance Testing

Endurance Testing
Transaction Testing Load Testing Stress Testing Robustness Testing Scalability Testing
(Longevity/Soak)

Measure respond time, maximum limit to Go beyond limits for extended intervals how resilient the if the system is
identify bottle necks work (Volume / the system to (e.g. 24 hour 365 system will be to capable of providing
Concurrent users) looking for days per year) , negative input expected service
unexpected results/ repeat a transaction
more than once
Sample of volume/stress testing : Analogy of an air-traffic control system keeping track of 200 planes
• Volume test is to see what happened with 40,50, 100 and 200 planes
• Stress test will see what happens when 201st plane enters

SF332 Software Testing and Quality Assurance 7

 Type of Performance Testing
Load testing
The load testing is used to check the performance of an
application by applying some load which is either less than
or equal to the desired load is known as load testing.
For example: In the below image, 1000 users are
the desired load, which is given by the customer,
and 3/second is the goal which we want to achieve while
performing a load testing.
Stress Testing
The stress testing is testing, which checks the behavior of an
application by applying load greater than the desired load.
For example: If we took the above example and increased
the desired load 1000 to 1100 users, and the goal is
4/second. While performing the stress testing in this scenario,
it will pass because the load is greater (100 up) than the
actual desired load.

1000 users – 3/sec 1100 users –> 4/sec

Desired Goal Increased Goal

load desired load

Ref: https://www.javatpoint.com/performance-testing
SF332 Software Testing and Quality Assurance 8
 Type of Performance Testing
Scalability testing
Checking the performance of an application by increasing or
decreasing the load in particular scales (no of a user) is
known as scalability testing. Scalability testing is divided into
two parts which are as follows:

Upward scalability testing Downward scalability testing

It is testing where we increase the number of users on The downward scalability testing is used when the load
a particular scale until we get a crash point. We will use testing is not passed, then start decreasing the no. of
upward scalability testing to find the maximum capacity users in a particular interval until the goal is achieved.
of an application. So that it is easy to identify the bottleneck (bug).

Ref: https://www.javatpoint.com/performance-testing
SF332 Software Testing and Quality Assurance 9
 Performance Testing Example
100 up users are increased continuously to check
Let us take one example where we will test the behavior of
the maximum load => upward scalability testing.
an application where the desired load is either less than
Pass
1000 or equal to 1000 users. 1000 users – 2.7/sec
100
•Scenario1: When we have the 1000 users as desired load, and the 2.7/sec is goal time, Load Testing
assume desired load is increased ( )
these scenarios will pass while performing the load test because in load testing, we will Pass
concentrate on the no. of users, and as per the requirement it is equal to 1000 user. 1100 users – 3.5/sec
100
•Scenario2: In the next scenario, we will increase the desired load by 100 users, and Stress Testing
assume desired load is again increased ( )
goal time will go up to 3.5\sec. This scenario will pass if we perform stress testing
because here, the actual load is greater than (1100) the desired load (1000). 100
1200 users – 3.5/sec
•Scenario3: In this, if we increase the desired load three times as
1200 → 3.5\sec: [it is not less than or equal to the desired load that's why it will Fail]
1300 → 4\sec: [it is not less than or equal to the desired load. i.e., Fail] 1300 users – 4/sec
100
1400 → Crashed

1400 users – crashed

Ref: https://www.javatpoint.com/performance-testing
SF332 Software Testing and Quality Assurance 10
 Agenda
Performance Efficiency
(ISO/IEC25010:2011)

Type of Performance Testing

Performance Testing Process

Performance Testing Tools

SF332 Software Testing and Quality Assurance 11

 Performance Testing Process
1. Identify performance
scenarios Set Test Objective/Goal
2. Plan and design
performance test script To identify the performance scenarios based on these below factors:
Most commonly scenarios: It means that we can find the performance scenarios based
3. Configure the test
environment & distribute on the scenarios, which commonly used like in the Gmail application; we will
the load perform login, inbox, send items, and compose a mail and logout.
4. Execute test scripts
Most critical scenarios: Critical scenarios mean regularly used and important for the
business-like in Gmail application login, compose, inbox, and logout.
5. Result

Huge data transaction: If we have huge data means that n-number of the users using
6. Analysis result the application at the same time.

- Install tools
7. Identify the Bottleneck
- Access the test server
- Write script according to the test scenarios and run the tool
8. Re-run test

Ref: https://www.javatpoint.com/performance-testing
SF332 Software Testing and Quality Assurance 12
 Performance Testing Process
1. Identify performance
scenarios - arrange the testing environment before the execution.
- manage the tools, other resources and distribute the load according to the
2. Plan and design
performance test script "Usage Pattern"

3. Configure the test - execute, validate, and monitor the test scripts
environment & distribute
the load
- check that the result meeting the goal in the given response time or not, and
4. Execute test scripts
the response time could be maximum, average, and minimum
- analyze the test result whether it meets with the response time or not.
5. Result
- identify the bottleneck (bug or performance issue).
6. Analysis result
And the bottleneck could occur because of these aspects like the problem in code, hardware issue
(hard disk, RAM Processor), network issues, and the software issue (operating system). And after
finding the bottleneck, we will perform tuning (fix or adjustment) to resolve this bottleneck.
7. Identify the Bottleneck

- fix the bottlenecks, re-run the test scripts

8. Re-run test - checks the result whether it meets the required goal or not.
Ref: https://www.javatpoint.com/performance-testing
SF332 Software Testing and Quality Assurance 13
 The problem occurs in performance testing
(Performance Issue)
Response time
• The response timeissue
means how quickly the server respond to Speed issue
the client's request. If the user's request does not complete in
• When we perform performance testing on the application, the
the given response time, it might have possible that the user
application should be faster in speed to get the user's interest and
may be lost his/her interest in the particular software or
attention because if the application's speed is slow, it may lose the
application. That's why the application or software should have a
user interest in the application.
perfect response time for responding user's request quickly.
Bottleneck
Scalability issue • The Bottleneck is the informal name of bug, which occurs when the
application is limited by a single component and creates a bad impact
• The scalability issues occur when the application cannot take on the system performance.
the n-numbers of users and expected user requests at the
• The main causes of bottlenecking are software issues (issue related
same time.
to the operating system), hardware issues (issues related to the
• That's why we will do upward scalability testing (check the hard disk, RAM and the processor), and coding issue, etc.
maximum capacity of the application) and downward scalability Most common performance bottlenecks:
testing (when expected time is not matched with the actual • Memory utilization • CPU utilization •Network utilization
time). • Disk usage • Operating System limitations
SF332 Software Testing and Quality Assurance 14
 Performance Testing Process - Example
1. Identify performance
scenarios
2. Plan and design
performance test script
3. Configure the test
environment & distribute
the load
4. Execute test scripts
5. Result
6. Analysis result
7. Identify the Bottleneck
8. Re-run test
Ref: https://medium.com/@kit.kmutnb/performance-test-คืออะไร-ทาไปทาไมกันนะ
SF332 Software Testing and Quality Assurance
Test Objective/Goal : อยำกลด Cost ค่ำใช้จ่ำยของระบบ เรำสำมำรถลด hardware spec บน Cloud ได้ไหมนะ
Simulate scenario production สาหรับทา Load Test
=> ให้ Simulate scenario จาก Peak hour transaction
- Monitor server resource ที่ Production ก่อนว่ามีการใช้งานอยู่เยอะมากไหม
- response time ช้าหรือไม่
- ถ้า server resource ใช้งานอยู่เยอะมากมาย response ช้ามาก
Ans : ลดไม่ได้แล้ว อาจจะต้องเพิ่มด้วยซ้า
- แต่ถ้าดูแล้ว server resource ใช้งานไม่เยอะมาก response time ก็ ok ไม่ช้า
Ans : Go on
Create Environment สาหรับ Load Test
Ex. เริ่มจากทา server size ให้เท่า Production
หรือ ครึ่งนึงของ Production Spec
15
 Performance Testing Process - Example
1. Identify performance
scenarios
2. Plan and design
performance test script
3. Configure the test
environment & distribute
the load
4. Execute test scripts
5. Result
6. Analysis result
7. Identify the Bottleneck
8. Re-run test
Ref: https://medium.com/@kit.kmutnb/performance-test-คืออะไร-ทาไปทาไมกันนะ
SF332 Software Testing and Quality Assurance
- เอา Scenario production มาทาการ Load Test ใน Environment ที่เตรียมไว้
- Monitor
1) Response time
2) Server resource
3) TPS (Transaction per sec)
=> Result ที่ได้ออกมารับได้ไหม
กรณีที่ Result ออกมา Ok
Response time , Server resource , TPS => ok
เราอาจจะ Retest อีกครั้งนึงเพื่อมั่นใจในการทดสอบ
กรณีที่ Result ออกมา ไม่ Ok
เราก็ปรับขยาย Size ของ server ให้เพิ่มขึน้ แล้วทา
การ Load Test อีกครั้งไปจนเจอจุดที่รับได้
(Response time , server resource, TPS ได้
result ใกล้เคียงกับที่ Production เป็นอยู่)
สรุป จากตัวอย่าง ถ้าเราใช้ Cloud environment ที่ spec ใหญ่
ทุกเครื่อง แล้วถ้าเราสามารถลด spec production ได้ อาจจะเป็น
1/2 หรือ 3/4 ของ spec ที่ใช้อยู่ได้ก็สามารถ cost ในการเช่า
Cloud ได้ในระดับนึงแล้ว
เช่น
ยกตัวอย่างสมมุติปกติเราใช้ Production server on cloud spec
เป็น [ CPU 32 core , Mem 32 GB ] cost per month
200,000 baht
จากผลการ test เราสรุปได้ว่าเราใช้แค่ CPU 16 core Memory
16 GB cost per month อาจจะอยู่ที่ 120,000 baht จะทาให้
เห็นว่าสามารถลดค่าใช้จ่ายในการเช่า cloud ลงไปได้
ข้อเสนอแนะเพิ่มเติม เมื่อปรับลด spec ที่ production จริงแล้ว
ในช่วงแรกควรมีการ monitor อย่างใกล้ชิด และ มี solution
สารองในการแก้ปัญหาเผื่อไว้ด้วย
16
 Performance Testing value
Throughout คืออะไร
Speed
- จานวน transaction/request ที่ถูกสร้างขึ้นหรือทางานได้ในช่วงเวลาการทดสอบหนึ่งๆ
- Formula: Throughout = จานวน request หรือ transaction
Resource Response จานวนเวลาการทางานรวม
Usage Time - ต้องกาหนดค่าเป้าหมายเสมอ เช่น
Performanc จานวนใน 1 วินาที นาที ชั่วโมง
e Test

- หน่วย : transaction per second (TPS)

จานวน transaction ที่ทางานใน 1 วินาที
Stability Throughout

แต่ถำ้ มีงำนจำนวน 10 งำนเข้ำมำ

ตัวอย่างเช่น พร้อมๆ กันใน 1 นำที
ระบบงานสามารถทางานได้ 5 งานพร้อมๆ กันใน 1 นาที ซึง่ จำนวนงำนเกินควำมสำมำรถของ
ดังนั้น ถ้ามีงานเข้ามา 5 งานพร้อมๆ กัน ระบบงำน
ระบบจะสามารถทางานทั้ง 5 งานได้พร้อมๆ กัน โดยไม่มีงานใดรอเข้าทางานเลย ดังนัน้ จะมีงำนจำนวน 5 งำนที่ตอ้ ง
แสดงว่าระบบงานมีค่า Throughput = 5 ต่อ 1 นาที เข้ำคิวเพื่อรอทำงำน

Ref: https://www.somkiat.cc/performance-testing-about-throughput/
SF332 Software Testing and Quality Assurance 17
 Difficulties - อุปสรรคในการทา Non-functional Testing
• Lack of performance objectives , Ambiguous/ immeasurable objective, Poor requirement /
ไม่มีวัตถุประสงค์หรือมีแต่กากวม ตรวจวัดไม่ได้ ข้อกาหนดไม่ชัดเจน
• Poor environment, use of test tools, unable to recreate customer environment
สภาพแวดล้อมไม่ดี การใช้เครื่องมือ การสร้างสภาพแวดล้อมให้ใกล้เคียงกับของลูกค้านั้นไม่ได้
• Testing cost exceeds system cost, uncontrolled workload on the system during performance testing /
ค่าใช้จ่าย
• Lack of specialized knowledge /ขาดผู้เชี่ยวชาญ
• Change of software could mean change in performance / ซอฟต์แวร์เปลี่ยน สมรรถนะซอฟต์แวร์ก็เปลี่ยน
• Lack of time for performance testing to be done well /ไม่มีเวลาจะทาให้ดี

SF332 Software Testing and Quality Assurance 18

 Agenda
Performance Efficiency
(ISO/IEC25010:2011)

Type of Performance Testing

Performance Testing Process

Performance Testing Tools

SF332 Software Testing and Quality Assurance 19

 Performance Testing Tools
Open-source tool: Jmeter
https://jmeter.apache.org/

Commercial tools: LoadRunner[HP], WebLOAD, NeoLoad

https://www.radview.com/schedule-demo
SF332 Software Testing and Quality Assurance 20
 JMeter
JMeter หรือชื่อจริงว่า Apache JMeter https://jmeter.apache.org/
สามารถทดสอบผ่าน protocol ต่าง ๆ ได้ดังนี้
•
Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
• SOAP / REST Webservices
• FTP
• Database via JDBC
• LDAP
• Message-oriented middleware (MOM) via JMS
• Mail - SMTP(S), POP3(S) and IMAP(S)
• Native commands or shell scripts
• TCP
• Java Objects
SF332 Software Testing and Quality Assurance 21
 Jmeter Plugins
http://jmeter-plugins.org/
เพื่อเพิ่มฟีเจอร์ที่ช่วยอานวยความสะดวกในการทาการทดสอบด้วยดังนี้
•jp@gc — Stepping Thread Group: สาหรับใส่จานวนผู้ใช้จาลอง •jp@gc — Response Codes per Second:
ตั้งแต่จุดที่เริ่มต้นทดสอบและเพิ่ม/ลดจานวน thread ตามระยะเวลาได้ สาหรับตรวจสอบว่าระบบยังตอบสนองกลับมาเป็น 200 OK อยู่ ไม่ใช่
อย่างสะดวก ว่า response กลับมาเร็วแต่เป็น 500 Internal Server Error ฯลฯ

•jp@gc — Response Time vs Threads: เป็นหน้าหลักที่เราใช้ •jp@gc — Response Times Distribution:

ตรวจสอบการตอบสนองของระบบ เราสามารถเช็คได้ว่าระบบเริ่มรองรับ แสดง distribution graph ให้เห็นว่าการกระจายตัวของ response
ไม่ไหวจากกราฟ Response Time ที่เริ่มทะยานขึ้นได้ time จาแนกตามหน้าที่ยิง

•jp@gc — Active Threads Over Time: สาหรับเช็คจานวนผู้ใช้ที่

เราจาลองขึ้น ณ จุดใดจุดหนึ่งของการทดสอบ

Ref: https://blog.maqe.com/load-testing-แบบลูกทุ่งด้วย-apache-jmeter-b9ac33476657
SF332 Software Testing and Quality Assurance 22
 ตัวอย่างการทา Test Plan ด้วย jmeter
plugins jp@gc — Stepping Thread Group

SF332 Software Testing and Quality Assurance 23

JMeter plugins jp@gc

SF332 Software Testing and Quality Assurance 24

 jp@gc — Response Times Over Time -> ดูการตอบสนองของ Response Times

SF332 Software Testing and Quality Assurance 25

 jp@gc — Active Threads Over Time -> จานวนผู้ใช้ที่จาลองขึ้นในการทดสอบ

SF332 Software Testing and Quality Assurance 26

 Results - 1
กราฟ response time vs active threads
แสดงให้เห็นว่าระบบตอบสนองได้เสถียรดีไปตลอดจนถึง 400 threads
กราฟสีฟ้าๆ คาดว่าเป็นปัญหาภายในเน็ตเวิร์คของบริษัทเอง
ส่วนค่าแกน Y ที่สูงอย่าไปสนใจมันมาก เทสระบบอ้อมไปครึ่งโลก
แถมทดสอบครั้งนี้ก่อนหน้าที่จะทา optimization ด้วย

Ref: https://blog.maqe.com/load-testing-แบบลูกทุ่งด้วย-apache-jmeter-b9ac33476657
SF332 Software Testing and Quality Assurance 27
 Results - 2
กราฟ response time vs active threads
ระบบยังตอบสนองได้ดีจนถึง 400 active threads
ทดสอบอีกครั้งโดยเพิ่ม max. active threads ให้สูงขึ้นไปอีก
แสดงให้เห็นชัดเจนว่าด้วย configuration นี้ ระบบเริ่มไม่เสถียรตั้งแต่ 400 threads เป็นต้นไป
และแสดงให้เห็นด้วยว่า endpoint สีฟ้า ถึงแม้ response time จะสูสีกับคนอื่นมาตลอด
กลายเป็นตัวแรกที่แสดงอาการเมื่อโหลดสูงขึ้น

Ref: https://blog.maqe.com/load-testing-แบบลูกทุ่งด้วย-apache-jmeter-b9ac33476657
SF332 Software Testing and Quality Assurance 28
 Results - 3
ระบบที่ทดสอบมี New Relic APM
(Application Performance
Monitoring), New Relic Servers
(Server Monitoring) และ Amazon
CloudWatch อยู่แล้ว เราจึงใช้อย่าง
เต็มที่เพื่อเก็บข้อมูลอื่นๆ ซึ่งทาให้เรา
เข้าใจระบบของเรามากขึ้นไปอีก

Ref: https://blog.maqe.com/load-testing-แบบลูกทุ่งด้วย-apache-jmeter-b9ac33476657
SF332 Software Testing and Quality Assurance 29
 Results - 4
Amazon CloudWatch
ฝั่ง Database
ทาให้เราสังเกตการณ์โหลดบน
ฐานข้อมูลได้เช่นกัน

Ref: https://blog.maqe.com/load-testing-แบบลูกทุ่งด้วย-apache-jmeter-b9ac33476657
SF332 Software Testing and Quality Assurance 30
 Example #1 - 1 เมื่อจานวน request สูงขึ้นมาเรื่อยๆ ค่าของ Throughput ก็เพิ่มมากขึ้นเช่นกัน
เมื่อไรก็ตามที่จานวน request และ จานวนการประมวลผลของระบบการทดสอบเริ่มนิง่
ก่อนการทดสอบ นั่นแสดงว่า ค่าของ Throughput ของระบบนั่นนิ่งหรือเสถียรแล้วเช่นกัน
ต้องทาการกาหนด หรือ สร้างจานวน request หรือ ผู้ใช้งานขึ้นมาก่อน
โดยจานวน request จะค่อยๆ ถูกสร้างขึ้นมาในรูปแบบ ramp up

ค่า Throughput ของระบบ เมื่อเพิ่มจานวน request เข้ามาด้วย JMeter

คาอธิบาย
จะทาการสร้าง 100 request ภายใน 10 วินาที
ดังนั้น จะทาการสร้าง 10 request ต่อ 1 วินาทีนั่นเอง
Ref: https://www.somkiat.cc/performance-testing-about-throughput/
SF332 Software Testing and Quality Assurance 31
 Example #1 - 2
ต้องการรู้ว่า ค่า Throughput จะสามารถเพิ่มขึ้นได้อีกหรือไม่ ?
- เพิ่มจานวน request ที่ส่งเข้ามาทดสอบระบบ
ถ้าการเพิ่มจานวน request ทาให้ค่า Throughput ลดลงมา
แสดงว่ามีส่วนใดส่วนหนึ่งในระบบงานเกิดปัญหาคอขวดมาแล้ว
หรือนั่นคือ เกินขีดความสามารถของระบบในตอนนั้น
รูปตัวอย่างแสดงระบบเกิดปัญหาคอขวดขึ้น
Ref: https://www.somkiat.cc/performance-testing-about-throughput/
SF332 Software Testing and Quality Assurance
เช่น
เข้าคิวเพื่อรอทางานนานเกินไป เช่น CPU, database และ network เป็นต้น
ส่งผลให้ response time สูงขึ้นมาก จนเกิด timeout
โดยจาเป็นต้องนาข้อมูลจากระบบ monitoring อื่นๆ
เข้ามาพิจารณาด้วยนะครับ เช่น Monitoring server, access log เป็นต้น
เพื่อทาให้การวิเคราะห์ผล มีประสิทธิภาพและถูกต้องมากยิ่งขึ้น
32
 Example #2 Load testing ก่อนและหลังทา code optimization
หลังจากที่ได้ผลลัพธ์ข้างต้น เราได้หยิบ 2 endpoints มาทา code optimization เพื่อให้โค๊ดใช้ทรัพยากรระบบลดลง
ปรากฎว่าการเปรียบเทียบผลลัพธ์ระหว่างก่อนและหลังการทา optimization ยิ่งมีความน่าสนใจเข้าไปอีก

เพราะนอกจากมันจะทาให้ endpoint ทั้งสอง

ประมวลผลเร็วขึ้นแล้ว ยังทาให้ระบบโดยรวมมี
response time เร็วขึ้นสูงสุดกว่า 5 เท่า
แต่ความเสถียรกลับผันผวนมากขึ้น
ตั้งแต่ 320 threads ขึ้นไป
(ยังเร็วกว่าก่อน optimization อยู่ด)ี

ซึ่งแสดงให้เห็นว่าการทา load testing

เป็นระยะๆ จะทาให้เราเห็นและทาความเข้าใจ
พฤติกรรมของระบบได้ดีขึ้น

Ref: https://www.somkiat.cc/performance-testing-about-throughput/
SF332 Software Testing and Quality Assurance 33
SF332 Software Testing and Quality Assurance 34