Gatling for Load Tests part 5

load scenarios

เรายังคงใช้โปรเจกต์ที่สร้างจาก sbt (test framework) จาก part ที่ผ่านมา

Gatling for Load Tests part 4

Google ไปว่า

gatling cheat sheet

Gatling Open-Source Load Testing Documentation - For DevOps and CI/CD

Scenario

• scenario(name) ตั้งชื่อ scenario เห็นที่ report ด้วย

Base structures

• exec(action) ทำ action
• pause(dur unit) หยุดคอยตามเวลาที่กำหนด
• pause(dur unit, dur unit) หยุดคอยแบบสุ่มระหว่างสองช่วงเวลาที่กำหนด

Loops

• forever(counterName){chain} ให้ทำ chain ไปเรื่อยๆ

Open injection steps

• atOnceUsers(nbUsers) ระบุจำนวน user ที่ต้องการให้เข้าใช้งานในเวลาเดียวกัน (concurrent)
• rampUsers(nbUsers) during(dur unit) ระบุจำนวน user ซึ่งจะถูกเพิ่มเข้าไปจนกว่าจะครบจำนวนตามระยะเวลาที่กำหนด
• constantUsersPerSec(nbUsers) during(dur unit) เพิ่มจำนวน user ตามวินาทีไปจนกว่าจะครบเวลาที่กำหนด
• nothingFor(dur unit) อยู่เฉยๆตามระยะเวลาที่กำหนด

ไว้ศึกษาเพิ่มเติมก็จะนำมาแปะให้อ่านกันต่อไป

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

ยังไม่รู้จัก RESTful API อ่านก่อน

Spring Boot with RESTful Web Services

ใครถนัดเขียน RESTful API ง่ายๆไวๆจะใช้ภาษาไหนก็ตามใจชอบ หรือจะใช้ที่เขาเขียนกันไว้แล้วก็มีมากมาย หรือจะใช้เว็บที่เขาให้บริการ demo RESTful API นี้ก็ได้ ตัวอย่าง

JSONPlaceholder

ซึ่งมี resources ให้ใช้ เช่น

GET /posts คือขอโพสต์ทั้งหมด

GET /posts/1 คือขอโพสต์ที่มี ID เท่ากับ 1

GET /comments คือขอความเห็นทั้งหมด

POST /posts คือเขียนโพสต์

PUT /post/1 คือแก้ไขโพสต์ที่มี ID เท่ากับ 1

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

เตรียมโปรเจกต์เอง

ผมสร้างโปรเจกต์แบบเดียวกันไว้ 2 เทคโนโลยี ชื่อว่า bookdb ทั้งสองใช้ฐานข้อมูลเดียวกัน (MS SQL Server version 2017)

1. เขียนด้วย Golang
2. เขียนด้วย Kotlin

ต่างก็เป็น RESTful Web Service ที่ประกอบด้วย

GET /books ขอหนังสือทั้งหมด

GET /books/{id} ขอหนังสือหนึ่งเล่มโดยเลือกจาก ID

POST /books เพิ่มหนังสือหนึ่งเล่ม

PUT /books/{id} แก้ไขหนังสือหนึ่งเล่มโดยเลือกจาก ID

DELETE /books/{id} ลบหนังสือหนึ่งเล่มโดยเลือกจาก ID

โปรเจกต์ bookdb เขียนด้วย Golang

หัด Golang part 5

โปรเจกต์ bookdb เขียนด้วย Kotlin

proSbeginner/bookdb-kotlin

Scenario 1: AddPauseTime

พฤติกรรมคือ

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

โค้ดทั้งหมด

เข้า sbt mode แล้วรัน

gatling:testOnly com.pros.AddPauseTime

ผลลัพธ์ Kotlin และ Golang ตามลำดับ

Kotlin Report

Golang Report

จากรูปของสอง reports ข้างต้นไม่ได้ต้องการนำเสนอว่า Kotlin vs Golang แต่ต้องการนำเสนอหน้าตาของ report ของสองเทคโนโลยีเฉยๆ หัวใจสำคัญคือสถานการณ์เป็นแบบสุ่มการรอคอย (pause time) ที่คาดเดาไม่ได้ว่าเลขสุ่มจะออกมาเท่าไรโดยเฉพาะ “สุ่มหยุดไปอีก 1 ถึง 10 วินาทีก่อนจะกลับไปหน้าแรก”

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

• 5 คน
• 500 คน
• และ 5,000 คน
• อะไรนะ 50,000 คน (บ้าไปแล้ว)

แก้ไขที่บรรทัดนี้นะ

scen.inject(atOnceUsers(1))

Let Get Started!

scen.inject(atOnceUsers(5))

Kotlin มาแบบนิ่มๆ น้อยกว่า 800ms ทั้งหมด

Golang ครับ จัดว่าแจ่มอยู่ตามมาติดๆ

scen.inject(atOnceUsers(500))

Kotlin งานนี้มีเป๋มากกว่า 1.2s อยู่ 21 ราย

Golang อะไรยังไง 611 รายรั้งท้ายเลยเหรอ?

scen.inject(atOnceUsers(5000))

Kotlin ที่ 5000 คน เกือบสลบ

แต่ Golang ที่ 5000 คน ตายสนิท 13711 คน

scen.inject(atOnceUsers(50000))

Kotlin ไปได้แค่ 17 + 34 + 35520 ที่เหลือ 14429 รายตายเรียบ

และที่ 50000 คนนี้ Golang ตายหมด ผมตกใจเห็นเป็น 0 หมดยกเว้น failed นึกไปว่าไปกดโดนอะไรหรือเปล่า เปล่าครับ ที่ 50000 นี้คือ server ล่ม ดูภาพ

Golang ตายหมด

ความเห็น

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

มาถึงตรงนี้ ผมขอไป refresh page localhost:8080/books ที่เขียนด้วย Kotlin อีกสักทีนะ

ฮั่นแน่ ร้ายนะเรา

ส่วน Golang ผมก็ต้องกลับไปอ่านเรื่อง Concurrency ผมว่าเทคโนโลยีของมันน่าจะโหดมากและผมยังใช้มันไม่เป็น อย่างไรผมก็ยังเป็นมือใหม่ ขอดีคือศึกษาได้เรื่อยๆทั้งยังผิดได้อีกมาก ผมจะกลัวอะไรล่ะ ตั้งใจฝึกฝนลับคมต่อไปสิเออ

โอกาสหน้า part ใหม่เรามาดู scenario อื่นๆต่อกันนะครับ