Dạo này không có ý tưởng cho viết blog, cũng ko có nhiều thời gian để đào sâu vào 1 thứ gì đó để chia sẻ, nên mình tìm 1 câu hỏi trên fb group TestingVN để comment trả lời. Câu hỏi này có nhiều bạn trả lời với nhiều góc độ khác nhau, mình thấy các câu trả lời đều rất hay nên muốn viết vài bình luận cho từng câu trả lời đó. Mình không có đi gây War, không có thiếu gạch xây nhà, chỉ muốn thảo luận thêm chút kiến thức.

Link câu hỏi: đây nhé

I. Câu hỏi

II. Các câu trả lời

Mình đồng tình với cách trả lời này, vì cơ bản cái câu hỏi “trường hợp nào performance chạy ổn định hơn” không rõ ràng. Hỏi cái gì ổn định? test ổn định hay system/app ổn định. Và thế quái nào là “ổn định”? —-> cảm thấy mệt mỏi khi gặp người nào phỏng vấn kiểu thế này.

Mình giả định rằng, người phỏng vấn đang nói đến tool JMeter thì:

• 100 Threads, loop=10 thì có nghĩa JMeter sẽ tạo 100 threads (cái này cũng là OS Threads luôn) và mỗi thread sẽ run cái test plan đủ 10 lần rồi close. Có nghĩa là trong 1 thời điểm, có 100 users đang tương tác với system.
• 1000 Threads, loop=1 —-> tổng số sẽ có 1000 users tương tác với system, tuy nhiên ko có nghĩa là cả 1000 user trong 1 thời điểm. Hãy nhớ rằng, 1000 OS Threads được tạo ra rồi chờ tới lượt để run (đã nói ở bài Thread), và có thể thread 1, 2 hoặc nhiều threads khác đã run xong trước khi Thread cuối cùng finish. Do đó, ko biết được 1 thời điểm thì có bao nhiêu users đang tương tác với app.

Và mình cũng đồng tình luôn là thời gian test quá ngắn, cũng như là đây là 2 cases khác nhau về mục đích.

Chắc bạn nghĩ “tính ổn định” ở đây có nghĩa là case 1 thì system/app run nhẹ nhàng hơn là case 2 –> system/app sẽ handle tốt hơn. Điều này đúng về mặt logic, dù gì thì 100 users cùng lúc cũng nhẹ hơn 400, 500 hay 1000 users cùng lúc.

Cũng có ý chung với câu trả lời của các bạn ở trên, bạn ý đưa thêm 2 thông tin thú vị:

1. So sánh với peak của hệ thống hiện tại thì mới kết luận được có “ổn định” hay ko? Nhắc lại, mình ko biết cái từ “ổn định” của câu hỏi có nghĩa là gì.
2. Spike test tăng giảm đột ngột request + cloud auto scale –> gây lỗi. Mình ko biết mấy về cloud nhưng chẳng phải auto scale để đối phó với tăng giảm đột ngột số request hay sao? huh, ai biết trả lời giùm với.

Đây là 1 câu trả lời thú vị khi so sánh “xử lý và duy trì” vs “xử lý và không duy trì”. Tuy nhiên thú vị chưa chắc đã hoàn toàn toàn đúng (với góc nhìn của mình).

Theo mình hiểu “duy trì trạng thái người dùng” của bạn nói tới là “server đang phải keep track hoạt động của 1 user và sẽ keep memory, CPU cho user đó”.

• Mình đang giả định dùng HTTP làm protocol cho câu hỏi này. HTTP là giao tiếp stateless (không trạng thái), server sẽ xử lý mọi request giống nhau, nó ko phân biệt được request của user A hay request của user B, mọi thông tin để process request phải được chứa đựng trong các thành phần của request (method, header, body). Và server cũng chẳng thể nào biết được user khi nào sẽ tiếp tục dùng app để mà keep cái gì vào temporary memory cả. Do đó, server chẳng keep track cái gì cho mỗi user hết, nếu muốn save state thì nó save luôn vào DB, rồi lần sau user request lên, nó sẽ query state từ DB ra.
• Về phía Server, thông thường để xử lý 1 request từ client gửi lên, nó sẽ có 1 Thread để handle. Thread này có thể được tạo ra từ OS Threads, hoặc lightweight Thread (tùy thuộc vào mỗi ngôn ngữ lập trình). Cái Thread này khi run thì nó sẽ dùng CPU và RAM, cache… Tuy nhiên khi nó process xong thì nó sẽ bị kill hoặc trở lại Thread pool. Và khi nó được kill thì nó không dùng CPU nữa và stack memory cũng được dọn sạch, các objects được tạo ra sẽ được Garbage Collector thu lại. –> ko tốn CPU và memory.

Tuy nhiên vẫn có điểm đáng nhắc tới, đó là việc hold TCP connection. HTTP được run trên nền của TCP nên:

• TH 1: Sẽ tạo 100 TCP connection và nó sẽ được keep ở phía server để client có thể gửi thêm nhiều request mà ko cần tạo thêm TCP connection –> giảm thời gian connect giữa client và server. Server, cụ thể là Web Server, cái đang host của app của bạn như Apache, NGINX, IIS… sẽ làm việc này, chứ không phải cái system/app của bạn làm việc này. Điều này dẫn đến Server sẽ tốn thêm RAM để hold connection chứ ko phải Server tốn thêm RAM để hold User state.
• TH2: Sẽ tạo ra 1000 TCP connection và ko được tái sử dụng –> dùng xong bỏ luôn, ko hold connection.

• Cái gì ở trong View Result Tree có thể trả lời câu hỏi này. Nếu chỉ là response time thì Summary Report hay Aggregate Report cũng có mà. Không rõ có thông tin nào mà chỉ View Result Tree mới có và chỉ có thông tin đó mới trả lời được câu hỏi? mình tò mò điểm này.
• Phần “lão làng” trong nghề mình ko có ý kiến vì nằm ngoài câu hỏi.

Yeah, mình thấy cũng khá hợp lý, mặc dù mình ko run load test đến vài tiếng bao giờ.

III. Tổng kết

Câu hỏi của người phỏng vấn có thể mập mờ, thiếu thông tin, nên các bạn trước khi trả lời hãy hỏi đủ ngữ cảnh, các chi tiết liên quan trước để không mất công trả lời sai “ý muốn” của người phỏng vấn. Vì trả lời đúng theo ý của bạn mà sai theo ý của người phỏng vấn thì bạn trượt. =))))