Cách đánh giá độ trễ HTTP theo chuẩn với wrk trên Ubuntu 14.04

Bài viết này tập trung vào một công cụ đo điểm chuẩn HTTP open-souce được gọi là wrk , công cụ này đo độ trễ của các dịch vụ HTTP của bạn khi tải cao .

---

Độ trễ đề cập đến khoảng thời gian giữa thời điểm yêu cầu được thực hiện (theo tuần) và thời điểm nhận được phản hồi (từ dịch vụ). Điều này được dùng để mô phỏng độ trễ mà khách truy cập sẽ gặp phải trên trang web khi truy cập trang bằng trình duyệt hoặc bất kỳ phương pháp nào khác gửi yêu cầu HTTP.

wrk hữu ích để kiểm tra bất kỳ trang web hoặc ứng dụng nào dựa trên HTTP, chẳng hạn như:

• Rails và các ứng dụng Ruby khác
• Express và các ứng dụng JavaScript khác
• Ứng dụng PHP
• Các trang web tĩnh chạy trên web server
• Các trang web và ứng dụng đằng sau bộ cân bằng tải như Nginx
• Lớp bộ nhớ đệm của bạn

Các thử nghiệm không thể so sánh với user thực , nhưng chúng sẽ cung cấp cho bạn ước tính tốt về độ trễ dự kiến để bạn có thể lập kế hoạch cơ sở hạ tầng của bạn tốt hơn. Các bài kiểm tra cũng có thể cung cấp cho bạn cái nhìn sâu sắc về các node thắt hiệu suất của bạn.

wrk là open-souce và có thể tìm thấy trên GitHub .

Nó rất ổn định và cho phép mô phỏng tải cao nhờ tính chất đa stream của nó. Tính năng lớn nhất của wrk là khả năng tích hợp các tập lệnh Lua , bổ sung nhiều khả năng như:

• Yêu cầu đo điểm chuẩn với cookie
• Báo cáo tùy chỉnh
• Đo điểm chuẩn nhiều URL - điều mà ab phổ biến, công cụ đo điểm chuẩn server Apache HTTP, không thể

Yêu cầu

Cơ sở hạ tầng mà ta sẽ sử dụng trong hướng dẫn này được trình bày trong sơ đồ dưới đây:

Như bạn thấy , ta sẽ sử dụng wrk trong một kịch bản rất đơn giản. Ta sẽ đánh giá một ứng dụng Express trên Node.js.

Ta sẽ tạo ra hai server : một cho wrk, tạo ra tải và một cho ứng dụng. Nếu chúng ở trên cùng một ô, chúng sẽ cạnh tranh nhau để giành tài nguyên và kết quả của ta sẽ không tin cậy .

Máy có điểm chuẩn phải đủ mạnh để xử lý hệ thống căng thẳng, nhưng trong trường hợp của ta , ứng dụng quá đơn giản nên ta sẽ sử dụng các máy có cùng kích thước.

• Quay hai server trong cùng một vùng vì chúng sẽ giao tiếp bằng IP riêng
• Gọi một Server wrk1 và app1 khác, để làm theo hướng dẫn này
• Chọn bộ nhớ 2 GB
• Chọn Ubuntu 14.04
• Chọn Mạng riêng trong phần Cài đặt Có sẵn
• Tạo một user sudo trên mỗi server

Các server nhỏ hơn cũng sẽ hoạt động, nhưng bạn nên mong đợi nhiều độ trễ hơn trong kết quả thử nghiệm. Trong môi trường thử nghiệm thực, server ứng dụng của bạn phải có cùng kích thước mà bạn dự định sử dụng trong production .

Nếu bạn cần trợ giúp cài đặt Server, vui lòng tham khảo bài viết này .

Bước 1 - Cả hai server : Cài đặt Docker

Để làm cho cuộc sống của ta dễ dàng hơn, ta sẽ sử dụng Docker , vì vậy ta có thể bắt đầu wrk và ứng dụng của ta bên trong các container . Điều đó cho phép ta bỏ qua việc cài đặt môi trường Node.js, module npm và gói gỡ lỗi; tất cả những gì ta cần là download và chạy containers thích hợp. Thời gian dành dụm được sẽ đầu tư vào việc học wrk.

Nếu bạn chưa quen với Docker, bạn có thể đọc phần giới thiệu về nó tại đây .

Lưu ý: Các lệnh trong phần này phải được thực hiện trên cả hai Server .

Để cài đặt Docker, hãy đăng nhập vào server của bạn và thực hiện các lệnh sau. Đầu tiên, hãy cập nhật danh sách gói:

sudo apt-get update 

Cài đặt Wget và cURL:

sudo apt-get install -y wget curl 

Download và cài đặt Docker:

sudo wget -qO- https://get.docker.com/ | sh 

Thêm user của bạn vào group docker để bạn có thể thực thi các lệnh Docker mà không cần sudo:

sudo gpasswd -a ${USER} docker 
sudo service docker restart 
newgrp docker 

Nếu bạn đang sử dụng bản phân phối Linux khác, Docker có tài liệu cài đặt có thể sẽ giải quyết trường hợp của bạn.

Để xác minh docker được cài đặt chính xác, hãy sử dụng lệnh này:

docker --version 

Bạn sẽ nhận được kết quả sau hoặc kết quả tương tự:

Output
Docker version 1.7.1, build 786b29d 

Bước 2 - Chuẩn bị ứng dụng thử nghiệm

Thực thi các lệnh này trên App1 Server.

Với mục đích thử nghiệm, tác giả đã xuất bản Docker image trong register Docker công khai. Nó chứa một ứng dụng gỡ lỗi HTTP được viết bằng Node.js. Nó không phải là một con thú hiệu suất ( ta sẽ không phá vỡ bất kỳ kỷ lục nào hôm nay) nhưng nó đủ để kiểm tra và gỡ lỗi. Bạn có thể kiểm tra mã nguồn ở đây .

Tất nhiên, trong một tình huống thực tế, bạn cần thử nghiệm ứng dụng của chính mình.

Trước khi bắt đầu ứng dụng, hãy lưu địa chỉ IP riêng của Server vào một biến có tên APP1_PRIVATE_IP :

export APP1_PRIVATE_IP=$(sudo ifconfig eth1 | egrep -o "inet addr:[^ ]*" | awk -F ":" '{print $2}') 

Bạn có thể xem IP riêng với:

echo $APP1_PRIVATE_IP 

Đầu ra:

Output
10.135.232.163 

Địa chỉ IP riêng của bạn sẽ khác, vì vậy hãy ghi lại địa chỉ đó.

Bạn cũng có thể lấy IP riêng từ console digitalocean.com . Chỉ cần chọn Server và sau đó đi tới phần Cài đặt như được trình bày trong hình ảnh bên dưới:

Bây giờ khởi động ứng dụng đơn giản bằng cách chạy lệnh này:

docker run -d -p $APP1_PRIVATE_IP:3000:3000 --name=http-debugging-application czerasz/http-debugger 

Lệnh trên trước tiên sẽ download Docker image được yêu cầu, sau đó chạy một containers Docker. Vùng chứa được khởi động ở chế độ tách rời , nghĩa là nó sẽ chạy ở chế độ nền. Tùy chọn -p $APP1_PRIVATE_IP:3000:3000 sẽ ủy quyền tất cả lưu lượng truy cập đến và đi từ containers local trên cổng 3000 và đến và đi từ IP riêng của server trên cổng 3000 .

Sơ đồ dưới đây mô tả tình huống này:

Bây giờ hãy kiểm tra với curl để xem ứng dụng có đang chạy hay không:

curl -i -XPOST http://$APP1_PRIVATE_IP:3000/test -d 'test=true' 

Sản lượng mong đợi:

Output
HTTP/1.1 200 OK X-Powered-By: Express X-Debug: true Content-Type: text/html; charset=utf-8 Content-Length: 2 ETag: W/"2-79dcdd47" Date: Wed, 13 May 2015 16:25:37 GMT Connection: keep-alive  ok 

Ứng dụng này rất đơn giản và chỉ trả về một thông báo ok . Vì vậy, mỗi lần wrk yêu cầu ứng dụng này, nó sẽ nhận được một thông báo ok nhỏ trở lại.

Phần quan trọng nhất là ta có thể xem những yêu cầu nào được thực hiện bởi wrk đối với ứng dụng của ta bằng cách phân tích log ứng dụng.

Xem log ứng dụng bằng lệnh sau:

docker logs -f --tail=20 http-debugging-application 

Đầu ra mẫu của bạn sẽ giống như sau:

Output
[2015-05-13 16:25:37] Request 1  POST/1.1 /test on :::3000  Headers:  - user-agent: curl/7.38.0  - host: 0.0.0.0:32769  - accept: */*  - content-length: 9  - content-type: application/x-www-form-urlencoded  No cookies  Body: test=true 

Bạn có thể để điều này chạy trong khi chạy các bài kiểm tra điểm chuẩn của bạn , nếu bạn muốn. Thoát khỏi đuôi bằng CTRL-C .

Bước 3 - Cài đặt wrk

Đăng nhập vào server wrk1 và sẵn sàng cài đặt wrk.

Vì ta có Docker nên rất dễ dàng. Chỉ cần download hình ảnh williamyeh/wrk từ trung tâm đăng ký Docker bằng lệnh này:

docker pull williamyeh/wrk 

Lệnh trên download Docker image có chứa wrk. Ta không cần xây dựng wrk, cũng như cài đặt bất kỳ gói bổ sung nào. Để chạy wrk (bên trong containers ), ta chỉ cần khởi động containers dựa trên hình ảnh này, điều này ta sẽ thực hiện ngay sau đây.

Quá trình download chỉ mất vài giây vì hình ảnh rất nhỏ - dưới 3 MB. Nếu bạn muốn cài đặt wrk trực tiếp trên bản phân phối Linux yêu thích của bạn , hãy truy cập trang wiki này và làm theo hướng dẫn.

Ta cũng sẽ đặt biến APP1_PRIVATE_IP trên server này. Ta cần địa chỉ IP riêng từ server app1 .

Xuất biến với:

export APP1_PRIVATE_IP=10.135.232.163 

Hãy nhớ thay đổi địa chỉ IP 10.135.232.163 IP riêng của app1 Server. Biến này sẽ chỉ được lưu trong phiên hiện tại, vì vậy hãy nhớ cài đặt lại nó trong lần đăng nhập tiếp theo để sử dụng wrk.

Bước 4 - Chạy kiểm tra điểm chuẩn wrk

Trong phần này, cuối cùng ta sẽ thấy wrk hoạt động.

Tất cả các lệnh trong phần này phải được thực hiện trên wrk1 Server.

Hãy xem các tùy chọn mà wrk có sẵn cho ta . Chạy containers wrk chỉ với cờ --version sẽ in ra một bản tóm tắt ngắn gọn về cách sử dụng của nó:

docker run --rm williamyeh/wrk --version 

Đầu ra:

Output
wrk 4.0.0 [epoll] Copyright (C) 2012 Will Glozer Usage: wrk <options> <url>   Options:     -c, --connections <N>  Connections to keep open     -d, --duration    <T>  Duration of test     -t, --threads     <N>  Number of threads to use      -s, --script      <S>  Load Lua script file     -H, --header      <H>  Add header to request         --latency          Print latency statistics         --timeout     <T>  Socket/request timeout     -v, --version          Print version details    Numeric arguments may include a SI unit (1k, 1M, 1G)   Time arguments may include a time unit (2s, 2m, 2h) 

Bây giờ ta đã có một cái nhìn tổng quan, hãy soạn lệnh để chạy thử nghiệm của ta . Lưu ý lệnh này sẽ không thực hiện bất cứ điều gì, vì ta không chạy nó từ bên trong containers .

Trường hợp đơn giản nhất mà ta có thể chạy với wrk là:

wrk -t2 -c5 -d5s -H 'Host: example.com' --timeout 2s http://$APP1_PRIVATE_IP:3000/ 

Nghĩa là:

• -t2 : Sử dụng hai chủ đề riêng biệt
• -c5 : Mở sáu kết nối (máy khách đầu tiên bằng 0)
• -d5s : Chạy thử nghiệm trong năm giây
• -H 'Host: example.com' : Chuyển tiêu đề Host
• --timeout 2s : Xác định thời gian chờ hai giây
• http://$APP1_PRIVATE_IP:3000/ Ứng dụng đích đang lắng nghe trên $APP1_PRIVATE_IP:3000
• Đánh giá đường dẫn / đường dẫn ứng dụng của ta

Đây cũng có thể được mô tả là sáu user yêu cầu trang chủ của ta liên tục trong năm giây.

Hình minh họa dưới đây cho thấy tình huống này:

Lưu ý các kết nối không thể được so sánh với user thực bởi vì user thực cũng sẽ download các file CSS, hình ảnh và JavaScript trong khi xem trang chủ của bạn.

Đây là lệnh thực tế cho bài kiểm tra:

Hãy chạy kịch bản được mô tả trong containers Docker wrk của ta :

docker run --rm williamyeh/wrk -t2 -c5 -d5s -H 'Host: example.com' --timeout 2s http://$APP1_PRIVATE_IP:3000/ 

Chờ một vài giây để kiểm tra chạy và xem kết quả mà ta sẽ phân tích trong bước tiếp theo.

Bước 5 - Đánh giá kết quả

Đầu ra:

Output
Running 5s test @ http://10.135.232.163:3000   2 threads and 5 connections   Thread Stats   Avg      Stdev     Max   +/- Stdev     Latency     3.82ms    2.64ms  26.68ms   85.81%     Req/Sec   550.90    202.40     0.98k    68.00%   5494 requests in 5.01s, 1.05MB read Requests/sec:   1096.54 Transfer/sec:    215.24KB 

• Tóm tắt cấu hình hiện tại:

  Running 5s test @ http://10.135.232.163:3000   2 threads and 5 connections 

  Tại đây, ta có thể xem một bản tóm tắt ngắn gọn về cấu hình điểm chuẩn của bạn . Quá trình benchmark diễn ra trong 5 giây, IP của máy được benchmark là 10.135.232.163 và bài kiểm tra sử dụng hai stream .

• Các thông số phân phối chuẩn cho thống kê độ trễ và yêu cầu / giây:

  Thread Stats   Avg      Stdev     Max   +/- Stdev   Latency     3.82ms    2.64ms  26.68ms   85.81%   Req/Sec   550.90    202.40     0.98k    68.00% 

  Phần này cho ta thấy các chi tiết về phân phối chuẩn cho điểm chuẩn của ta - một hàm Gaussian sẽ có những tham số nào.

  Điểm chuẩn không phải lúc nào cũng có phân phối bình thường và đó là lý do tại sao những kết quả này có thể bị sai lệch. Do đó, hãy luôn xem xét các giá trị Max và +/- Stdev . Nếu những giá trị đó cao, thì bạn có thể mong đợi rằng phân phối của bạn có thể có phần đuôi nặng.

• Thống kê về số lượng yêu cầu, dữ liệu đã truyền và thông lượng:

    5494 requests in 5.01s, 1.05MB read Requests/sec:   1096.54 Transfer/sec:    215.24KB 

  Ở đây ta thấy rằng trong repository ảng thời gian 5.01 giây, wrk có thể thực hiện 5494 yêu cầu và truyền 1.05MB dữ liệu. Kết hợp với phép toán đơn giản ( total number of requrests/benchmark duration yêu cầu total number of requrests/benchmark duration ), ta nhận được kết quả là 1096.54 yêu cầu mỗi giây.

Nói chung, bạn đặt càng nhiều khách hàng, bạn sẽ nhận được ít yêu cầu hơn mỗi giây. Độ trễ cũng sẽ tăng lên. Điều này là do ứng dụng sẽ chịu tải nặng hơn.

Kết quả nào là tốt nhất?

Mục tiêu của bạn là giữ cho Requests/sec càng cao càng tốt và Latency thấp nhất có thể.

Tốt nhất, độ trễ không nên quá cao, ít nhất là đối với các trang web. Giới hạn cho thời gian tải trang với nội dung là tối ưu khi khoảng hai giây trở xuống.

Đến đây bạn có thể sẽ tự hỏi mình: Liệu 550.90 Requests/sec với độ trễ 3.82ms có phải là kết quả tốt không? Thật không may, không có câu trả lời dễ dàng. Nó phụ thuộc vào nhiều yếu tố như:

• Số lượng khách hàng, như ta đã thảo luận trước đây
• Tài nguyên server - nó là một version lớn hay nhỏ?
• Số lượng máy phục vụ ứng dụng
• Loại dịch vụ của bạn - đó là bộ nhớ đệm phân phát file tĩnh hay server quảng cáo phân phát phản hồi động?
• Loại database , kích thước cụm database , kiểu kết nối database
• Loại yêu cầu và phản hồi - đó là một yêu cầu AJAX nhỏ hay một lệnh gọi API béo?
• Và nhiều người khác

Bước 6 - Thực hiện hành động để cải thiện độ trễ

Nếu bạn không hài lòng với hiệu suất dịch vụ của bạn , bạn có thể:

• Điều chỉnh dịch vụ của bạn - kiểm tra mã của bạn và xem những gì có thể được thực hiện hiệu quả hơn
• Kiểm tra database của bạn để xem liệu đó có phải là nút cổ chai của bạn không
• Chia tỷ lệ theo chiều dọc - thêm tài nguyên vào máy của bạn
• Chia tỷ lệ theo chiều ngang - thêm một version khác của dịch vụ của bạn và thêm nó vào bộ cân bằng tải
• Thêm một lớp bộ nhớ đệm

Để có thảo luận chi tiết hơn về các cải tiến ứng dụng, hãy xem 5 Cách Cải thiện Cài đặt Server Ứng dụng Web Sản xuất của bạn .

Hãy nhớ đánh giá tiêu chuẩn dịch vụ của bạn sau khi áp dụng các thay đổi cho nó - chỉ khi đó, bạn mới có thể chắc chắn rằng dịch vụ của bạn đã được cải thiện.

Vậy đó, bạn có thể nghĩ, nếu không có thứ Lua này…

Mô phỏng các yêu cầu HTTP nâng cao với Lua Scripts

Vì wrk có tích hợp sẵn LuaJIT (Just-In-Time Compiler cho Lua) nên nó có thể được mở rộng với các tập lệnh Lua. Như đã đề cập trong phần giới thiệu, điều này bổ sung rất nhiều chức năng cho wrk.

Sử dụng tập lệnh Lua với wrk rất đơn giản. Chỉ cần nối đường dẫn file vào cờ -s .

Vì ta sử dụng wrk bên trong Docker, trước tiên ta phải chia sẻ file này với containers . Điều này có thể đạt được với tùy chọn -v của Docker.

Các phần của tập lệnh Lua cho tuần lễ

Ở dạng chung, sử dụng một tập lệnh có tên là test.lua , toàn bộ lệnh có thể trông như thế này:

docker run --rm -v `pwd`/scripts:/scripts williamyeh/wrk -c1 -t1 -d5s -s /scripts/test.lua http://$APP1_PRIVATE_IP:3000 

Ta đã giải thích lệnh wrk và các tùy chọn của nó ở bước trước. Lệnh này không thêm quá nhiều nữa; chỉ là đường dẫn đến tập lệnh và một số lệnh bổ sung để cho Docker biết cách tìm nó bên ngoài containers .

Cờ --rm sẽ tự động xóa containers sau khi nó dừng.

Nhưng ta có thực sự biết cách viết kịch bản Lua không? Đừng sợ hãi; bạn sẽ học nó một cách dễ dàng. Ta sẽ xem xét một ví dụ đơn giản ở đây và bạn có thể tự chạy các tập lệnh nâng cao hơn của riêng mình.

Đầu tiên ta hãy nói về cấu trúc script được định nghĩa phản ánh logic bên trong của wrk. Sơ đồ dưới đây minh họa nó cho một chủ đề:

wrk thực hiện các giai đoạn thực thi sau:

• Phân giải địa chỉ IP của domain
• Bắt đầu với cài đặt chuỗi
• Thực hiện giai đoạn kiểm tra căng thẳng , được gọi là giai đoạn chạy
• Bước cuối cùng được gọi là hoàn thành đơn giản

Khi sử dụng một số stream , bạn sẽ có một giai đoạn phân giải và một giai đoạn hoàn thành, nhưng hai giai đoạn cài đặt và hai giai đoạn chạy:

Ngoài ra, giai đoạn chạy có thể được chia thành ba bước: init , request và response .

Theo sơ đồ được trình bày và tài liệu, ta có thể sử dụng các phương pháp sau bên trong tập lệnh Lua:

• setup(thread) : Được thực thi khi tất cả các stream đã được khởi tạo nhưng chưa bắt đầu. Được sử dụng để chuyển dữ liệu đến chuỗi

• init(args) : Được gọi khi mỗi stream được khởi tạo

  Hàm này nhận các đối số dòng lệnh bổ sung cho tập lệnh phải được tách biệt với các đối số wrk bằng -- .

  Thí dụ:

  wrk -c3 -d1s -t2 -s /scripts/debug.lua http://$APP1_PRIVATE_IP:3000 -- debug true 

• request() : Cần trả về đối tượng HTTP cho mỗi yêu cầu. Trong hàm này, ta có thể sửa đổi phương thức, tiêu đề, đường dẫn và nội dung

  Sử dụng hàm trợ giúp wrk.format để định hình đối tượng yêu cầu.

  Thí dụ:

  return wrk.format(method, path, headers, body) 

• response(status, headers, body) : Được gọi khi phản hồi trở lại

• done(summary, latency, requests) : Được thực thi khi tất cả các yêu cầu hoàn tất và thống kê được tính toán

  Bên trong hàm này có các thuộc tính sau:

  Bất động sản	Sự miêu tả
  summary.duration	thời lượng chạy tính bằng micro giây
  summary.requests	tổng số yêu cầu đã hoàn thành
  summary.bytes	tổng số byte nhận được
  summary.errors.connect	tổng số lỗi kết nối socket
  summary.errors.read	tổng số lỗi đọc socket
  summary.errors.write	tổng số lỗi ghi socket
  summary.errors.status	tổng số mã trạng thái HTTP> 399
  summary.errors.timeout	tổng thời gian chờ yêu cầu
  latency.min	giá trị độ trễ tối thiểu đạt được trong khi kiểm tra
  latency.max	giá trị độ trễ tối đa đạt được trong quá trình thử nghiệm
  latency.mean	giá trị độ trễ trung bình đạt được trong quá trình thử nghiệm
  latency.stdev	độ lệch chuẩn độ trễ
  latency:percentile(99.0)	Giá trị phân vị thứ 99
  latency[i]	dữ liệu độ trễ thô của yêu cầu i

Mỗi stream có ngữ cảnh Lua riêng và trong đó có các biến local của riêng nó.

Bây giờ ta sẽ đi qua một vài ví dụ thực tế, nhưng bạn có thể tìm thấy nhiều tập lệnh đo điểm chuẩn hữu ích hơn trong thư mục scripts của dự án wrk.

Ví dụ: Yêu cầu POST

Hãy bắt đầu với ví dụ đơn giản nhất, nơi ta mô phỏng một yêu cầu POST .

Yêu cầu POST thường được sử dụng để gửi dữ liệu đến server . Điều này được dùng để đánh giá:

• Trình xử lý biểu mẫu HTML: Sử dụng địa chỉ có trong thuộc tính action của biểu mẫu HTML của bạn:

  <form action="/login.php"> ... </form> 

• Điểm cuối của POST API: Nếu bạn có một API còn hoạt động, hãy sử dụng điểm cuối nơi bạn tạo bài viết của bạn :

  POST /articles 

Bắt đầu bằng việc tạo file scripts/post.lua trên Server wrk1 .

cd ~ 
mkdir scripts 
nano scripts/post.lua 

Thêm vào đó nội dung sau:

wrk.method = "POST" wrk.body   = "login=sammy&password=test" wrk.headers["Content-Type"] = "application/x-www-form-urlencoded" 

Tập lệnh này rất đơn giản và ta thậm chí còn chưa sử dụng bất kỳ phương pháp nào được đề cập. Ta vừa sửa đổi các thuộc tính đối tượng wrk toàn cục.

Ta đã thay đổi phương thức yêu cầu thành POST , thêm một số thông số đăng nhập và chỉ định tiêu đề Content-Type để sử dụng biểu mẫu HTML kiểu MIME.

Trước khi ta bắt đầu điểm chuẩn, đây là sơ đồ để giúp bạn hình dung cách tập lệnh, containers Docker và server ứng dụng liên quan:

Bây giờ là thời điểm của sự thật - đánh giá ứng dụng bằng lệnh này (thực thi trên wrk1 Server):

docker run --rm -v `pwd`/scripts:/scripts williamyeh/wrk -c1 -t1 -d5s -s /scripts/post.lua http://$APP1_PRIVATE_IP:3000 

Đầu ra:

Output
Running 5s test @ http://10.135.232.163:3000   1 threads and 1 connections   Thread Stats   Avg      Stdev     Max   +/- Stdev     Latency     1.04ms  718.38us  12.28ms   90.99%     Req/Sec     1.02k   271.31     1.52k    66.00%   5058 requests in 5.00s, 0.97MB read Requests/sec:   1011.50 Transfer/sec:    198.55KB 

Đầu ra tương tự như kết quả mà ta đã thấy trước đó.

Lưu ý ta đang đo điểm chuẩn ở đây chỉ với một kết nối. Điều này tương ứng với tình huống chỉ một user muốn đăng nhập liên tục, chuyển tên user và password . Điều này không yêu cầu các file CSS, hình ảnh hoặc JavaScript nào.

Đối với một tình huống thực tế hơn, bạn nên tăng số lượng client và chuỗi, đồng thời quan sát tham số độ trễ, để xem ứng dụng có thể xác thực thông tin xác thực của user nhanh như thế nào.

Ví dụ: Nhiều đường dẫn URL

Một nhu cầu phổ biến khác là kiểm tra đồng thời nhiều đường dẫn của một ứng dụng.

Hãy tạo một file có tên là paths.txt trong folder data và thêm tất cả các đường dẫn mà ta muốn sử dụng trong quá trình chuẩn của ta .

cd ~ 
mkdir data 
nano data/paths.txt 

Tìm ví dụ về data/paths.txt bên dưới:

/feed.xml /contact/ /about/ /blog/ /2015/04/21/nginx-maintenance-mode/ /2015/01/06/vagrant-workflows/ /2014/12/10/top-vagrant-plugins/ 

Sau đó, lấy tập lệnh đơn giản này và lưu nó dưới dạng scripts/multiple-url-paths.lua :

-- Load URL paths from the file function load_url_paths_from_file(file)   lines = {}    -- Check if the file exists   -- Resource: http://stackoverflow.com/a/4991602/325852   local f=io.open(file,"r")   if f~=nil then     io.close(f)   else     -- Return the empty array     return lines   end    -- If the file exists loop through all its lines   -- and add them into the lines array   for line in io.lines(file) do     if not (line == '') then       lines[#lines + 1] = line     end   end    return lines end  -- Load URL paths from file paths = load_url_paths_from_file("/data/paths.txt")  print("multiplepaths: Found " .. #paths .. " paths")  -- Initialize the paths array iterator counter = 0  request = function()   -- Get the next paths array element   url_path = paths[counter]    counter = counter + 1    -- If the counter is longer than the paths array length then reset it   if counter > #paths then     counter = 0   end    -- Return the request object with the current URL path   return wrk.format(nil, url_path) end 

Mặc dù hướng dẫn này không cố gắng dạy cách viết kịch bản Lua một cách chi tiết, nhưng nếu bạn đọc các comment trong tập lệnh, bạn có thể hiểu rõ về những gì nó làm.

Tập lệnh multiple-url-paths.lua mở file /data/paths.txt và nếu file này chứa các đường dẫn, chúng sẽ được lưu vào một mảng paths nội bộ. Sau đó, với mỗi yêu cầu, đường dẫn tiếp theo được thực hiện.

Để chạy điểm chuẩn này, hãy sử dụng lệnh sau (thực thi trên server wrk1 ). Bạn sẽ nhận thấy ta đang thêm một số dấu ngắt dòng để sao chép dễ dàng hơn:

docker run --rm \ 
           -v `pwd`/scripts:/scripts \ 
           -v `pwd`/data:/data \ 
           williamyeh/wrk -c1 -t1 -d5s -s /scripts/multiple-url-paths.lua http://$APP1_PRIVATE_IP:3000 

Đầu ra:

Output
multiplepaths: Found 7 paths multiplepaths: Found 7 paths Running 5s test @ http://10.135.232.163:3000   1 threads and 1 connections   Thread Stats   Avg      Stdev     Max   +/- Stdev     Latency     0.92ms  466.59us   4.85ms   86.25%     Req/Sec     1.10k   204.08     1.45k    62.00%   5458 requests in 5.00s, 1.05MB read Requests/sec:   1091.11 Transfer/sec:    214.17KB 

Yêu cầu nâng cao với JSON và YAML

Đến đây bạn có thể nghĩ rằng các công cụ đo điểm chuẩn khác cũng có thể thực hiện các loại kiểm tra này. Tuy nhiên, wrk cũng có khả năng xử lý các yêu cầu HTTP nâng cao bằng cách sử dụng định dạng JSON hoặc YAML.

Ví dụ: bạn có thể tải file JSON hoặc YAML mô tả chi tiết từng yêu cầu.

Tác giả đã xuất bản một ví dụ nâng cao với yêu cầu JSON trên blog công nghệ của tác giả .

Bạn có thể chuẩn bất kỳ loại yêu cầu HTTP nào mà bạn có thể nghĩ đến, với wrk và Lua.

Kết luận

Sau khi đọc bài viết này, bạn có thể sử dụng wrk để đánh giá các ứng dụng của bạn . Lưu ý thêm, bạn cũng có thể thấy vẻ đẹp của Docker và cách nó có thể giảm thiểu đáng kể việc cài đặt ứng dụng và môi trường thử nghiệm của bạn.

Cuối cùng, bạn có thể đi xa hơn với các yêu cầu HTTP nâng cao bằng cách sử dụng tập lệnh Lua với wrk.

---

---

Các tin liên quan

Cách cài đặt và sử dụng Command Line Cheat Sheets trên Ubuntu 14.04
2015-07-21
Cách cài đặt và sử dụng CFEngine Community Edition trên Ubuntu 14.04
2015-07-17
Cách cài đặt và cấu hình Riak2 với Python3 trên Ubuntu 14.04
2015-07-14
Cách cài đặt Solr 5.2.1 trên Ubuntu 14.04
2015-07-14
Cách thiết lập R trên Ubuntu 14.04
2015-07-13
Cách triển khai ứng dụng Rails với Git Hooks trên Ubuntu 14.04
2015-07-09
Cách sử dụng Prometheus để giám sát server Ubuntu 14.04 của bạn
2015-06-30
Cách cài đặt control panel Ajenti và Ajenti V trên Ubuntu 14.04
2015-06-26
Cách tự động hóa cài đặt WordPress trên Ubuntu 14.04 bằng Ansible
2015-06-25
Cách cài đặt Công cụ giám sát Munin trên Ubuntu 14.04
2015-06-20