Cùng với việc các trang web cũng như các ứng dụng trên web ngày càng xuất hiện nhiều và phức tạp thì hiệu năng đang là thứ mà các developers cũng như người dùng quan tâm nhất. Những nghiên cứu gần đây cho thấy rằng những trang web có tốc độ truy cập nhanh sẽ có nhiều người dùng tương tác hơn từ đó họ có thể bán được nhiều sản phẩm hơn. Vì vậy hãy dành sự quan tâm đặc biệt tới việc làm thế nào để người dùng có thể truy cập trang web của bạn một cách nhanh chóng.
Thường thì người ta gọi việc này là web performance optimization, có nghĩa là tối ưu hóa hiệu năng của web. Vài năm trở lại đây đã có rất nhiều các cuộc thử nghiệm, kĩ thuật và công nghệ được phát triển để phục vụ cho mục đích này. Rất nhiều trong số đó tập trung chủ yếu vào việc giảm thời gian download web pages, tối ưu hóa JavaScript và giới hạn số lượng HTTP requests.
Trong bài viết này, chúng ta sẽ cùng bàn về một khía cạnh khác khi xét về việc tăng hiệu năng của 1 website. Đó hính là liệu server của bạn có đủ nhanh để trả lời lại các requests? Chúng tôi sẽ giới thiệu với các bạn về concept chung của load testing, đưa ra các bước để tìm ra thời gian trả lời tối đa của server đối với các requests và đồng thời đưa ra một vài phần mềm load testing mã nguồn mở.
Trước khi bắt đầu, hãy tìm hiểu về một số thuật ngữ:
-
Latencylà thước đo tốc độ mà server phản hồi lại requests từ client. Thường thì nó được đo bằng milliseconds (ms), Latency cũng thường được thay thế choresponse timetức là thời gian trả lời của server. Số càng nhỏ thì có nghĩa server phản hồi lại càng nhanh. Latency được đo từ phía client, tính từ thời gian gửi request cho tới khi nhận được request phản hồi về. -
Throughputlà số lượng requests mà server có thể tiếp nhận và xử lí trong một khoảng thời gian nhất định, thường được tính bằng số lượng requests trên giây -
Percentileslà cách mà ta nhóm kết quả theo % của toàn bộ sample set. Nếu thời gian phản hồi phần trăm thứ 50 của bạn là 100ms, điều đó có nghĩa là 50% yêu cầu đã được trả lại trong 100ms trở xuống. Biểu đồ dưới đây cho thấy lý do tại sao việc xem các phép đo của bạn bằng %:
Sơ đồ trên cho thấy độ trễ (Latency) của một web server trên một khoảng thời gian nhất định. Ngay cả khi thời gian phản hồi trung bình không có quá nhiều biến động thì vẫn có một lần tăng độ biến ở dòng phần trăm thứ 99. Điều này có nghĩa rằng 1% yêu cầu vẫn sẽ không được phản hồi hoặc phản hồi cực kì chậm.
Load testing là thực hiện gửi các bản tin mô phỏng HTTP request tới server nhằm mục đích đo hiệu năng và trả lời một số câu hỏi quan trọng:
- Máy chủ có đủ tài nguyên (CPU, bộ nhớ, vv) để xử lý bài test?
- Máy chủ có đáp ứng nhanh để cung cấp cho người dùng một trải nghiệm đủ tốt không?
- Ứng dụng có hoạt động hiệu quả không?
- Liệu chúng ta cần phải mở rộng phần cứng máy chủ, hoặc mở rộng ra nhiều máy chủ?
Load testing được thực hiện bằng cách chạy một phần mềm kiểm tra tải trên một máy (hoặc một cụm cluster) để generate ra một số lượng lớn các requests tới web server ở một máy chủ thứ 2 (hoặc một hệ thống các máy chủ chạy web). Có rất nhiều tools để thực hiện điều này, chúng ta sẽ bàn đến nó sau.
Phần lớn các phần mềm load testing là để tìm ra số lượng requests tối đa trên giây mà server có thể xử lí. Điều này được thực hiện bằng cách gửi tối đa requests tới máy chủ và xem nó có thể phản hồi thành công không.
Đây được coi là bước đầu tiên để có thể tìm ra khả năng tối đa của server nhưng nó không thực sự đem lại cho ta nhiều thông tin về Latency và hiệu năng thực mà người dùng được trải nghiệm hằng ngày. Một server tốt có thể trả lại hàng ngàn phản hồi trên 1 giây, nhưng nếu mỗi một phản hồi mất 10 giây thì chắc chắn người sử dụng sẽ không hài lòng.
Biểu đồ dưới đây mô tả mối quan hệ giữa throughput (phản hồi trên giây) và latency:
Đây chỉ là ví dụ, mỗi một cài đặt sẽ có một response profile riêng, nhưng xu hướng chung đó là càng nhiều requests trên giây thì latency càng cao. Để có được số liệu thực tế thì ta cần test nhiều lần ở nhiều tốc độ gửi requests khác nhau. Tuy vậy ngoài wrk2 thì không thực sự có nhiều phần mềm có thể thực hiện được điều này.
Có một vài bước để bạn có thể thấy được server và ứng dụng của bạn có đang hoạt động hiệu quả hay không. Đầu tiên, ta cần chắc chắn rằng bạn đang giám sát được tài nguyên của server mà bạn muốn test. Sau đó, ta sẽ tìm ra số lượng requests tối đa mà server có thể tiếp nhận và xử lí. Cuối cùng ta sẽ tìm ra số throughput tối đa mà ở đó độ trễ của server có thể gây khó chịu cho người dùng.
Bước 1: Giám sát tài nguyên
Các phần mềm load testing sẽ cho chúng ta thêm thông tin về requests cũng như latency nhưng nó cũng rất hữu dụng để giám sát một vài metrics hệ thống để ta biết được liệu server có thể chịu được khi có nhiều traffic hay không.
Chúng ta thường quan tâm nhiều tới CPU và RAM: Theo dõi hai thành phần này khi mà server đang chịu tải cao có thể giúp chung ta có thêm thông tin để đưa ra các quyết định về việc mở rộng hạ tầng hệ thống và đâu là điểm cần lưu ý khi phát triển ứng dụng.
Nếu bạn đã cài đặt hệ thống giám sát (ví dụ như Prometheus, Graphite và CollectD), bạn đã có thể thực hiện việc này. Nếu không, bạn có thể đăng nhập vào server thông qua ssh và sử dụng một số câu lệnh sau để giám sát:
Để check số lượng ram còn trống, bạn có thể sử dụng free. Kết hợp với watch để xem theo chu kì (mặc định là 2 giây)
watch free -h
-h để hiển thị theo dạng dễ đọc hơn thay vì hiển thị dưới dạng bytes:
Output
total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
-/+ buffers/cache: 39M 450M
Swap: 0B 0B 0BTa thấy 450M là số lượng RAM trống sau khi đã trừ đi việc sử dụng bộ nhớ đệm và cache. Một số phiêm bản mới của free có thể đưa ra kết quả như sau:
Output
total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M 260M
Swap: 0B 0B 0Bavailable được tính tương đối khác nhưng nhìn chung nó cho thấy cùng một metric đó là số lượng RAM đang còn trống mà ứng dụng có thể sử dụng.
Để giam sát CPU thì mpstat là một tool rất tốt. Ta có thể cài mpstat trên Ubuntu bằng câu lệnh sau:
sudo apt-get install sysstat
Khi bạn sử dụng mpstat, bạn cần cho nó biết số giây bạn muốn giữa các lần updates:
mpstat 2
Nó sẽ đưa ra thông số sau mỗi 2 giây:
Output
Linux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00%idle cho ta thấy phần trăm tài nguyên CPU chưa được sử dụng. Lí do mà ta nhìn %idle thay CPU đang được sử dụng bao nhiêu là bởi nó thường được chia ra các categories khác nhau như user CPU và system CPU.
Bước 2 — Tìm tốc độ phản hồi tối đa
Như đã nói ở trên, hầu hết các phần mềm load testing thường phù hợp nhất với việc tìm ra tốc độ phản hồi tối đa của webserver. Thường thì option duy nhất mà bạn cần set đó là concurrency thời gian test.
concurrency là số connections song song mà bạn tạo tới server. Số lượng mặc định là 100, bạn có thể xem thông số MaxClients, MaxThreads của server để biết được con số connections mà server có thể giải quyết.
Ngoài ra, bạn cần chọn một url dùng để test. Nếu phần mềm của bạn chỉ có thể sử dụng cho 1 url 1 lần thì bạn cần làm một vài test với các url khác nhau bởi yếu cầu xử lí có thể khác nhau khá nhiều (ví dụ giữa home page và product page).
Nếu phần mềm cho phép bạn sử dụng nhiều url để test một lần. Đây là cách rất tốt dể tìm ra tốc độ trong thực tế. Nếu bạn đã có số lượng thống kê của một site nào đó, bạn có thể so sánh với kết quả mà mình test được.
Khi chọn URL, cần chắc chắn rằng phần mềm của bạn có thể gửi request càng nhanh càng tốt. Nếu phần mềm cho phép bạn chọn tốc độ gửi request, hãy chọn số lớn nhất có thể. Nếu nó bắt phải chọn thời gian delay giữa các lần request, hãy giảm nó xuống 0.
Bạn nên quan sát số lượng CPU và RAM đang được sử dụng. Nếu CPU idle của bạn xuống 0% thì có thể máy mà bạn dùng để test có thể nhận lại một số lỗi kết nối bởi server đang phải giải quyết rất nhiều các requests. Điều này là bình thường bởi chúng ta đã đẩy server tới mức tối đa.
Sau khi quá trình này kết thúc, phần mềm sẽ đưa ra một số các thống kê bao gồm cả số lượng requests trên giây. Đối với thời gian phản hồi, nó có thể rất chậm bởi ta đã đẩy máy chủ nên tới giới hạn của nó. Vì vậy nên đây không phải là thông số tốt để có thể tính toán throughput thực tế nhưng nó sẽ là điểm khởi đầu cho những lần thử nghiệm tiếp theo.
Bước 3 - Tìm kiếm số lượng throughput lớn nhất
Đối với bước này, ta cần sử dụng một số phần mềm load testing có thể giảm tải lại một chút để có thể thử hiệu năng của server ở các mức độ throughput khác nhau. Một số phần mềm có thể làm được điều này bằng cách cho phép bạn chỉ định mức độ delay giữa các requests nhưng điều này làm cho việc xác định throughput không thực sự chính xác.
Rất may là wrk2 cho phép bạn chỉ định chính xác số lượng requests trên giây mong muốn. Nó có thể chạy trước được một số requests chuẩn để đo timing chính xác.
Hãy lấy tốc độ requests tối đa ở bước trước, cắt đi một nửa. Thực hiện thêm một test ở mức độ mới và note lại thời gian trả lời. Liệu nó có thể được coi là ở múc chấp nhận được hay không?
Nếu có, hãy quay trở lại với mức độ tối đa, hãy test cho tới khi latency của bạn đạt mức tối đa mà bạn coi là có thể chấp nhận được. Đây chính là tốc độ phần hồi tối đa thực tế mà server có thể đạt được.
Có rất nhiều các phần mềm mã nguồn mở dành cho việc này. Thêm vào đó, cũng có rất nhiều các dịch vụ mang tính thương mại phục vụ cho việc test hạ tầng của bạn và tự động tạo ra các biểu đồ, báo cáo dữ liệu...Các dịch vụ này có thể trở thành lựa chọn rất tốt cho các doanh nghiệp, những người cần generate ra một số lượng lớn các load test.
Một số phần mềm mã nguồn mở cũng có thể chạy được trên các cụm cluster. Hãy cùng điểm qua một vài cái tên nổi bật:
ab
ab (ApacheBench) là một công cụ command line đơn giản cho việc đo lường HTTP server. Mặc dù nó ban đầu chỉ là một phần của Apache HTTP Server nhưng bạn vẫn có thể dùng nó để test bất kì HTTP hoặc HTTPS server nào khác.
Bởi kiến trúc single-threaded, ab không thể sử dụng nhiều processors cùng lúc để gửi một số lượng lớn requests. Đây cũng là một hạn chế mà người dùng cần cân nhắc trước khi sử dụng.
Một câu lệnh ab cơ bản:
ab -n 1000 -c 100 http://example.com/
Số lượng requests (-n), số concurrency (-c) và truyền cho nó url. Output của nó chứa số lượng requests trên giây, thời gian request và danh sách các % thời gian phản hồi khác nhau:
Requests per second: 734.76
Time per request: 136.098 [ms] (mean)
Time per request: 1.361 [ms] (mean, across all concurrent requests)
Transfer rate: 60645.11 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)
50% 133
66% 135
75% 137
80% 139
90% 145
95% 149
98% 150
99% 151
100% 189 (longest request)JMeter
JMeter là một phần mềm thử nghiệm rất mạnh mẽ và nhiều tính năng của Apache Software Foundation. JMeter có thể test để chắc chắn rằng server của bạn cho ra đúng output.
JMeter có GUI để thiết lập test plan:
Test plan có thể được ghi lại bằng cách sử dụng JMeter's traffic recording web proxy và trình duyệt bình thường. Nó cho phép bạn test với traffic gần giống với bên ngoài thực tế.
Thêm vào đó, JMeter có thể cho ra báo cáo dưới định dạng html và nhiều định dạng khác nữa.
Siege
Siege là một công cụ command line khác dùng cho việc load testing. Giống với ab nhưng có một chút khác biệt đó là nó cho phép bạn sử dụng multiple URLs.
siege -c 100 -t 30s http://example.com/
Câu lệnh này gọi 100 concurrent requests (-c 100) trong 30 giây (-t 30s). Output của Siege chứa thời gian phải hồi trung bình và tốc độ requests:
. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Response time: 0.01 secs
Transaction rate: 197.15 trans/sec
Throughput: 4.59 MB/sec
Concurrency: 2.23Locust
Là một tool được viết bằng python với real-time web UI để giám sát kết quả:
Bạn viết ngữ cảnh test dưới dạng code python, nó cho phép một số tùy chọn cấu hình mạnh mẽ đối với những người đã quen với python.
Locust có thể chạy dưới mode distributed, tức là bạn có thể chạy một cụm cluster servers và cho phép chúng phối hợp với nhau để tạo số lượng tải lớn phục vụ cho những hệ thống web server mạnh mẽ.
Locust cũng có thể cung cấp số liệu thống kê dưới dạng file CSV.
wrk2
Là một multi-threaded command line load testing tool có khả năng tạo ra mức độ tải tùy chọn ở tốc độ gửi requests. Nó có thể cung cấp số liệu thống kê chi tiết về latency và được viết dưới dạng script sử dụng ngôn ngữ Lua.
wrk2 đi kem với câu lệnh wrk
wrk -t4 -c100 -d30s -R100 --latency http://example.com/
Câu lệnh phía trên khai báo 4 threads (-t4, bạn nên sử dụng theo số cores trên máy), 100 concurrent requests (-c100), trong 30 giây (-d30s) và tốc độ requests là 10 trên giây (-R100). Cuối cùng chúng ta request latency chi tiết với tùy chọn --latency:
Output
. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .Trong bài viết này, chúng ta đã review một số thuật ngữ và kiến thúc căn bản về load tesing, đi qua một số plan để tìm số lượng request lớn nhất có thể gửi trên 1 giây, quan sát tài nguyên để có thể đưa ra những quyết định trong tương lai về phần cứng và xem xét một số các phần mềm load testing mã nguồn mở.
Sau khi đã đo đạc về hiệu năng của hệ thống, bạn có thể dựa vào thông tin này để cải thiện thời gian phản hồi. Bạn có thể sẽ muốn cải thiện phần cứng hoặc gia tăng thêm số lượng servers và load balancer. Bạn cũng có thể tinh chỉnh cấu hình để tối ưu số lượng connections hoặc số lượng processes mà nó sử dụng. Bạn cũng có thể nhìn vào bộ nhớ đệm thường xuyên truy cập dữ liệu trong bộ nhớ, để giảm tải cơ sở dữ liệu và thời gian truy vấn.
Link bài viết:
https://www.digitalocean.com/community/tutorials/an-introduction-to-load-testing