Giới thiệu về Kiểm tra tải
Khi các trang web và ứng dụng web ngày càng có nhiều tính năng và phức tạp hơn, hiệu suất trở thành mối quan tâm lớn đối với các nhà phát triển cũng như user . Với các nghiên cứu cho thấy rằng các trang web nhanh hơn dẫn đến nhiều user tương tác hơn, bán được nhiều hơn và tăng lưu lượng truy cập, điều quan trọng là phải chú ý đến tốc độ bạn có thể cung cấp trang web của bạn cho user và hiển thị trang web của họ trong trình duyệt của họ.Thuật ngữ chung cho lĩnh vực kiến thức này là tối ưu hóa hiệu suất web và trong vài năm qua, nhiều phương pháp, kỹ thuật và công nghệ tốt nhất đã được phát triển để cải thiện trải nghiệm web. Nhiều kỹ thuật trong số này tập trung vào việc giảm kích thước download của các trang web, tối ưu hóa JavaScript và giới hạn số lượng yêu cầu HTTP riêng lẻ mà một trang cần.
Trong bài viết này, ta sẽ nói về khía cạnh khác của hiệu suất web: server của bạn có thể đáp ứng yêu cầu của user nhanh đến mức nào? Ta sẽ xem xét bối cảnh chung của kiểm tra tải, từng bước qua một kế hoạch để tìm tỷ lệ phản hồi thực tế tối đa của server của bạn và thảo luận về một số phần mềm kiểm tra tải open-souce .
Bảng chú giải
Trước khi bắt đầu, hãy làm rõ một số thuật ngữ và khái niệm có liên quan:
- Độ trễ là thước đo tốc độ phản hồi của server đối với các yêu cầu từ client . Thường được đo bằng mili giây (ms), độ trễ thường được gọi là thời gian phản hồi . Số thấp hơn cho thấy phản hồi nhanh hơn. Độ trễ được đo ở phía client , từ khi yêu cầu được gửi cho đến khi nhận được phản hồi. Chi phí mạng có trong số này.
- Thông lượng là số lượng yêu cầu mà server có thể xử lý trong một khoảng thời gian cụ thể, thường được báo cáo dưới dạng yêu cầu mỗi giây .
Phần trăm là một cách group các kết quả theo tỷ lệ phần trăm của toàn bộ tập mẫu. Nếu thời gian phản hồi phần trăm thứ 50 của bạn là 100 mili giây, điều đó nghĩa là 50% yêu cầu đã được trả lại trong 100 mili giây hoặc ít hơn. Biểu đồ bên dưới cho thấy lý do tại sao việc xem xét các phép đo của bạn theo phân vị lại hữu ích:
Biểu đồ trên cho thấy độ trễ của web server trong một khoảng thời gian. Mặc dù thời gian phản hồi trung bình (trung bình) khá nhất quán, nhưng vẫn có một sự đột biến lớn ở dòng phân vị thứ 99. Điều này nghĩa là 1% yêu cầu của user của ta thậm chí còn kém hơn phép đo phân vị thứ 99 này, trong khi mức trung bình vẫn tương đối ổn định. Vì lý do này, bạn nên xem xét các phân vị để có cảm nhận chính xác hơn về những gì user của bạn đang thực sự trải nghiệm.
Kiến thức cơ bản về kiểm tra tải
Kiểm tra tải là thực hành gửi truy cập HTTP mô phỏng đến server để đo lường hiệu suất và trả lời một số câu hỏi quan trọng, chẳng hạn như:
- Server có đủ tài nguyên (CPU, bộ nhớ, v.v.) để xử lý tải dự kiến không?
- Server có phản hồi đủ nhanh để cung cấp trải nghiệm user tốt không?
- Ứng dụng của ta có đang chạy hiệu quả không?
- Ta có cần mở rộng quy mô phần cứng server của bạn hay mở rộng ra nhiều server không?
- Có trang hoặc lệnh gọi API nào đặc biệt tốn nhiều tài nguyên không?
Kiểm tra tải được thực hiện bằng cách chạy phần mềm kiểm tra tải trên một máy (hoặc một cụm máy) để tạo ra một lượng lớn yêu cầu đến web server trên máy thứ hai (hoặc cơ sở hạ tầng phục vụ web phức tạp hơn).Có rất nhiều công cụ như vậy có sẵn và ta sẽ xem xét một số phần mềm cụ thể sau. Hiện tại, ta sẽ thảo luận về kiểm tra tải theo các thuật ngữ có liên quan cho dù bạn chọn phần mềm nào.
Một cách sử dụng phổ biến của phần mềm kiểm tra tải là tìm các yêu cầu tối đa mỗi giây mà server có thể xử lý. Điều này được thực hiện bằng cách gửi càng nhiều yêu cầu càng tốt đến một server và xem có bao nhiêu yêu cầu có thể trả về thành công.
Điều này hữu ích như là bước đầu tiên để hiểu công suất tối đa của server , nhưng nó không cung cấp cho ta nhiều thông tin về độ trễ và hiệu suất thực tế hàng ngày mà user của bạn sẽ trải nghiệm. Một server được tải nhiều có thể trả lại một nghìn phản hồi mỗi giây, nhưng nếu mỗi phản hồi mất mười giây, user của bạn có thể sẽ không hài lòng.
Biểu đồ bên dưới cho thấy mối quan hệ giữa thông lượng (phản hồi mỗi giây) và độ trễ:
Đây chỉ là một ví dụ và mọi cài đặt sẽ có một cấu hình phản hồi duy nhất, nhưng xu hướng chung là tải cao hơn (nhiều yêu cầu hơn mỗi giây) dẫn đến độ trễ cao hơn. Để có được ý tưởng thực tế hơn về độ trễ của server của ta ở một tải nhất định, ta cần kiểm tra nhiều lần ở các tỷ lệ yêu cầu khác nhau. Không phải tất cả phần mềm kiểm tra tải đều có khả năng này, nhưng sau này ta sẽ thảo luận về wrk2 , một công cụ kiểm tra tải dòng lệnh có thể thực hiện chức năng này.
Mục tiêu độ trễ hợp lý là gì?
Mặc dù thời gian tải trang web trong phạm vi 2–5 giây là phổ biến, nhưng phần thời gian đó được quy cho độ trễ của web server thường vào khoảng 50–200 mili giây. Điều gì phù hợp với bạn và trang web phụ thuộc vào quá nhiều yếu tố (đối tượng, thị trường, mục đích của trang web, trang web có phải là user trực tiếp hay dịch vụ API, v.v.) để đưa ra con số mục tiêu cụ thể hơn, nhưng hãy lưu ý hầu hết các nghiên cứu đều cho thấy rằng mọi tốc độ nhỏ đều có giá trị, và thậm chí những cải tiến “không thể nhận thấy” cũng dẫn đến kết quả tốt hơn khi xem tổng thể.
Bây giờ ta đã hiểu chung về thử nghiệm tải, hãy thảo luận về một kế hoạch cụ thể để khám phá hiệu suất của server của ta .
Kế hoạch kiểm tra tải
Có một vài bước chung mà bạn có thể thực hiện để biết server và ứng dụng web của bạn đang hoạt động như thế nào và phản hồi khi tải. Đầu tiên, ta sẽ đảm bảo ta đang theo dõi các tài nguyên hệ thống phù hợp trong quá trình kiểm tra tải. Sau đó, ta sẽ tìm ra các yêu cầu tối đa tuyệt đối mỗi giây mà server của ta có thể thực hiện. Cuối cùng, ta sẽ tìm ra thông lượng tối đa mà tại đó độ trễ của server của ta sẽ dẫn đến hiệu suất không thể chấp nhận được cho user của ta .
Bước 1 - Giám sát Tài nguyên
Phần mềm kiểm tra tải của ta sẽ cung cấp cho ta thông tin về các yêu cầu và độ trễ, nhưng sẽ hữu ích khi theo dõi một số chỉ số hệ thống khác để xem liệu server có bị hạn chế tài nguyên khi xử lý lưu lượng truy cập cao hay không.
Ta chủ yếu quan tâm đến tải CPU và bộ nhớ trống: xem những điều này khi tải nặng sẽ giúp bạn đưa ra quyết định sáng suốt hơn về cách mở rộng cơ sở hạ tầng và nơi tập trung nỗ lực khi phát triển ứng dụng của bạn.
Nếu bạn đã cài đặt hệ thống giám sát (chẳng hạn như Prometheus hoặc Graphite và CollectD ) thì bạn đã sẵn sàng. Nếu không, hãy đăng nhập vào web server của bạn qua SSH và sử dụng các công cụ dòng lệnh sau để theo dõi trong thời gian thực.
Để kiểm tra bộ nhớ khả dụng, bạn có thể sử dụng lệnh free . Kết hợp nó với watch để cập nhật định kỳ (hai giây một lần theo mặc định) kết quả :
- watch free -h
Cờ -h cho biết free xuất các số ở định dạng con người có thể đọc được thay vì byte:
Output total used free shared buffers cached Mem: 489M 261M 228M 352K 7.5M 213M -/+ buffers/cache: 39M 450M Swap: 0B 0B 0B Con số được đánh dấu trong kết quả ở trên đại diện cho bộ nhớ trống sau khi trừ sử dụng cache và cache . Các version free mới hơn đã thay đổi kết quả :
Output total used free shared buff/cache available Mem: 488M 182M 34M 14M 271M 260M Swap: 0B 0B 0B Cột available mới được tính hơi khác một chút, nhưng nhìn chung đại diện cho cùng một số liệu: bộ nhớ hiện có sẵn cho các ứng dụng sử dụng.
Để theo dõi việc sử dụng CPU từ dòng lệnh, mpstat là một tiện ích tốt cung cấp một cái nhìn cập nhật về lượng tài nguyên CPU nhàn rỗi. mpstat không được cài đặt theo mặc định trên Ubuntu. Bạn có thể cài đặt nó bằng lệnh sau:
- sudo apt-get install sysstat
Khi chạy mpstat bạn cần cho nó biết số giây bạn muốn giữa các lần cập nhật:
- mpstat 2
Điều này sẽ xuất ra một hàng tiêu đề, sau đó là một hàng thống kê cứ sau hai giây:
OutputLinux 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 không được sử dụng. Lý do ta xem xét mức độ nhàn rỗi thay vì mức độ được sử dụng là bởi vì việc sử dụng CPU thường được chia thành các loại khác nhau như CPU user và CPU hệ thống . Thay vì cộng dồn những thứ này một cách nhanh chóng, ta xem xét khía cạnh nhàn rỗi của phương trình.
Bây giờ ta có thể quan sát tài nguyên của server , hãy chạy thử nghiệm tải ban đầu để tìm tỷ lệ phản hồi tối đa của server .
Bước 2 - Tìm tỷ lệ phản hồi tối đa
Như đã đề cập trước đây, hầu hết các phần mềm kiểm tra tải đều đặc biệt thích hợp để tìm tỷ lệ phản hồi tối đa của web server của bạn. Thông thường, các tùy chọn duy nhất bạn cần đặt là đồng thời mong muốn và thời lượng kiểm tra.
Đồng thời là thước đo có bao nhiêu kết nối song song được thực hiện với server . 100 là một lựa chọn mặc định an toàn cho điều này, nhưng bạn có thể làm cho một sự lựa chọn thông tin hơn bằng cách kiểm tra web server của bạn MaxClients , MaxThreads , hoặc cài đặt tương tự để xác định có bao nhiêu kết nối đồng thời nó có thể xử lý.
Ngoài việc đặt các tùy chọn đó, bạn cần chọn một URL để sử dụng cho bài kiểm tra. Nếu phần mềm của bạn chỉ có thể xử lý một URL tại một thời điểm, thì bạn nên thực hiện nhiều thử nghiệm với một vài URL khác nhau, vì các yêu cầu xử lý có thể khác nhau rất nhiều giữa - ví dụ - trang chủ của bạn và trang sản phẩm yêu cầu tải nhiều truy vấn database .
Ngoài ra, một số phần mềm kiểm tra tải cho phép bạn chỉ định nhiều URL để kiểm tra cùng một lúc. Đây là một cách tốt để mô phỏng chính xác hơn lưu lượng truy cập trong thế giới thực. Nếu bạn có dữ liệu sử dụng trang web hiện tại (từ phần mềm phân tích hoặc log server ), bạn có thể đối sánh chặt chẽ các URL thử nghiệm của bạn với các giá trị quan sát được.
Khi bạn đã sắp xếp xong URL hoặc các URL để kiểm tra, hãy chạy kiểm tra tải. Đảm bảo rằng phần mềm của bạn đang gửi yêu cầu nhanh nhất có thể. Nếu bạn đang sử dụng phần mềm yêu cầu bạn chọn tỷ lệ yêu cầu, hãy chọn một giá trị gần như chắc chắn là quá lớn. Nếu phần mềm của bạn có độ trễ có thể cấu hình giữa các yêu cầu, hãy giảm nó xuống 0.
Bạn sẽ thấy tài nguyên CPU và bộ nhớ của bạn đang được sử dụng. CPU của bạn không hoạt động có thể đạt đến 0% và ứng dụng client kiểm tra tải của bạn có thể gặp một số lỗi kết nối do server của bạn phải vật lộn để theo kịp tất cả các yêu cầu. Điều này là bình thường, vì ta đang đẩy server đến giới hạn của nó.
Khi tất cả kết thúc, phần mềm của bạn sẽ xuất ra một số thống kê, bao gồm cả các yêu cầu mỗi giây . Cũng cần lưu ý thời gian phản hồi : nó có thể rất kém, vì server đáng lẽ phải hoạt động quá mức. Do đó, số lượng yêu cầu trên giây không phải là một chỉ báo tốt về thông lượng tối đa trong thế giới thực cho server của bạn, nhưng đó là điểm khởi đầu tốt để khám phá thêm.
Tiếp theo, ta sẽ quay lại quá trình tải và kiểm tra lại để có thêm thông tin về cách server của ta hoạt động khi nó không bị đẩy đến giới hạn tuyệt đối.
Bước 3 - Tìm thông lượng thực tế tối đa
Đối với bước này, ta cần sử dụng phần mềm kiểm tra tải có thể giảm tải một chút để kiểm tra hiệu suất server của ta ở các mức thông lượng khác nhau.Một số phần mềm thực hiện điều này bằng cách cho phép bạn chỉ định độ trễ giữa mỗi yêu cầu, nhưng điều này gây khó khăn cho việc nhắm đến thông lượng chính xác.
May mắn là wrk2 cho phép bạn chỉ định một yêu cầu chính xác cho mỗi mục tiêu giây. Nó thực hiện điều này bằng cách đầu tiên chạy một số yêu cầu hiệu chuẩn để có thời gian phù hợp.
Lấy tỷ lệ yêu cầu tối đa của bạn từ bước trước và cắt nó ra một nửa. Chạy thử nghiệm khác với tốc độ mới này và lưu ý thời gian phản hồi. Nó có còn trong phạm vi chấp nhận được không?
Nếu có, hãy tăng tốc độ lên mức tối đa, thử nghiệm khi bạn tiếp tục cho đến khi độ trễ của bạn ở giá trị tối đa mà bạn đã xác định là có thể chấp nhận được. Đây là tỷ lệ phản hồi tối đa thực tế mà server của bạn có thể xử lý trước khi user của bạn gặp phải tình trạng giảm hiệu suất.
Lưu ý: Như đã đề cập trong bảng thuật ngữ, khi đo độ trễ, bạn nên xem xét phân vị thứ 99 hoặc thậm chí là 99,999 đảm bảo rằng tất cả user của bạn thường xuyên gặp phải thời gian phản hồi dưới ngưỡng tối đa có thể chấp nhận được. Lưu ý hầu hết các trang web yêu cầu hàng tá yêu cầu để tìm nạp tất cả nội dung (bao gồm hình ảnh, JavaScript, file CSS, v.v.) và hiển thị trang. Nếu trang web cần mười yêu cầu để hoàn thành và bạn đang đo phần trăm thứ 99, thì khoảng 10% số lần tải trang web sẽ vẫn gặp một yêu cầu với độ trễ cao hơn.
Tiếp theo, ta sẽ xem xét một số gói phần mềm open-souce có sẵn để giúp ta triển khai kế hoạch thử nghiệm tải của bạn .
Tải phần mềm kiểm tra
Có nhiều gói phần mềm nguồn mở có sẵn để kiểm tra tải. Ngoài ra, có nhiều dịch vụ thương mại sẽ chạy cơ sở hạ tầng thử nghiệm tải cho bạn và tự động tạo đồ thị và báo cáo từ dữ liệu thử nghiệm. Các dịch vụ này có thể là lựa chọn tốt cho các doanh nghiệp cần tạo ra một lượng lớn tải để kiểm tra cơ sở hạ tầng quy mô lớn, vì hầu hết chúng chạy các cụm máy để tạo ra nhiều yêu cầu hơn một server duy nhất có thể.
Điều đó nói rằng, một số công cụ open-souce cũng có khả năng chạy ở chế độ cụm. Hãy xem qua một vài công cụ nguồn mở phổ biến hơn và tóm tắt các tính năng của chúng:
ab
ab ( còn gọi là ApacheBench) là một công cụ dòng lệnh đơn giản, đơn stream để đo điểm chuẩn cho một server HTTP. Mặc dù ban đầu nó được phân phối như một phần của Server Apache HTTP, bạn có thể sử dụng ab để kiểm tra bất kỳ server HTTP hoặc HTTPS nào.
Bởi vì nó là một stream , ab không thể tận dụng nhiều bộ xử lý để gửi một lượng lớn yêu cầu. Điều này có thể bị hạn chế nếu bạn đang cố gắng tải hoàn toàn một web server mạnh mẽ.
Lệnh gọi cơ bản của lệnh ab trông như thế này:
- ab -n 1000 -c 100 http://example.com/
Bạn chỉ định số lượng yêu cầu ( -n ) và đồng thời ( -c ), sau đó cung cấp cho nó một URL duy nhất để tìm nạp. Đầu ra - được trích dẫn bên dưới - chứa các yêu cầu trên giây, thời gian yêu cầu và danh sách các phần trăm thời gian phản hồi khác nhau:
Output. . . Requests per second: 734.76 [#/sec] (mean) 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 ứng dụng kiểm tra chức năng và kiểm tra tải mạnh mẽ và giàu tính năng của Apache Software Foundation. Kiểm tra chức năng nghĩa là JMeter cũng có thể kiểm tra đảm bảo trang web hoặc ứng dụng của bạn đang tạo ra kết quả chính xác.
JMeter có Java GUI để cài đặt Kế hoạch kiểm tra :
Các kế hoạch thử nghiệm có thể được ghi lại bằng cách sử dụng proxy web ghi lưu lượng của JMeter và một trình duyệt thông thường. Điều này cho phép bạn kiểm tra với lưu lượng truy cập mô phỏng chặt chẽ hơn việc sử dụng trong thế giới thực.
JMeter có thể xuất thông tin phần trăm trong báo cáo HTML và các định dạng khác.
Bao vây
Siege là một công cụ kiểm tra tải dòng lệnh khác, tương tự như ab nhưng có một vài tính năng khác. Siege là đa stream , cho phép thông lượng tương đối cao. Nó cũng cho phép bạn cung cấp danh sách nhiều URL sẽ được kiểm tra tải. Một lời gọi cơ bản sau:
- siege -c 100 -t 30s http://example.com/
Điều này yêu cầu 100 yêu cầu đồng thời ( -c 100 ) và kiểm tra ba mươi giây ( -t 30s ). Siege xuất ra thời gian phản hồi trung bình và tỷ lệ yêu cầu:
Output. . . 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.23 . . . Siege không cung cấp phân tích phần trăm cho thống kê độ trễ của nó.
Cào cào
Locust là một công cụ kiểm tra tải dựa trên Python với giao diện user web thời gian thực để theo dõi kết quả:
Bạn viết các kịch bản kiểm tra Locust bằng mã Python, cho phép một số cấu hình mạnh mẽ thuận tiện cho những người đã quen thuộc với ngôn ngữ này.
Locust cũng có thể được chạy ở chế độ phân tán , nơi bạn có thể chạy một cụm server Locust và để chúng tạo ra tải theo cách phối hợp. Điều này tạo điều kiện thuận lợi cho việc kiểm tra tải của cơ sở hạ tầng phục vụ web mạnh mẽ.
Locust có thể cung cấp số liệu thống kê chi tiết và thông tin phần trăm trong các file CSV có thể download .
wrk2
wrk2 là một công cụ kiểm tra tải dòng lệnh đa stream có khả năng tạo ra tải với tốc độ yêu cầu được chỉ định. Nó có thể cung cấp thống kê độ trễ chi tiết và có thể viết được bằng ngôn ngữ lập trình Lua.
wrk2 được gọi wrk lệnh wrk (nó là một nhánh của wrk root ):
- wrk -t4 -c100 -d30s -R100 --latency http://example.com/
Các tùy chọn trên chỉ định bốn stream ( -t4 , bạn nên sử dụng số lõi xử lý trên máy của bạn ), 100 yêu cầu đồng thời ( -c100 ), khoảng thời gian thử nghiệm 30 giây ( -d30s ) và tốc độ yêu cầu là 100 yêu cầu mỗi giây ( -R100 ). Cuối cùng, ta yêu cầu kết quả độ trễ chi tiết với --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 . . . Kết quả kết quả ở trên là một đoạn trích - phần trăm độ trễ chi tiết hơn cũng được in.
Kết luận
Trong bài viết này, ta đã xem xét một số thuật ngữ kiểm tra tải và các khái niệm cơ bản, xem xét một số kế hoạch để tìm ra các yêu cầu thực tế tối đa của ta mỗi giây, các tài nguyên hệ thống được quan sát để hướng dẫn các quyết định trong tương lai về phần cứng và nỗ lực phát triển cũng như xem xét một số open-souce có sẵn tải phần mềm kiểm tra.
Sau khi đo lường hiệu suất của cơ sở hạ tầng của bạn, bạn có thể cần xử lý thông tin này để cố gắng cải thiện thời gian phản hồi và giảm tải server . Bạn có thể cần mở rộng phần cứng web server của bạn hoặc mở rộng với nhiều server và bộ cân bằng tải. Bạn có thể cố gắng tinh chỉnh cấu hình web server của bạn để tối ưu hóa số lượng kết nối mà nó cho phép hoặc số lượng quy trình hoặc chuỗi hoạt động mà nó sử dụng. Bạn cũng có thể xem xét bộ nhớ đệm dữ liệu được truy cập thường xuyên trong bộ nhớ, để giảm tải database và thời gian truy vấn.
Bạn sẽ tìm thấy các chủ đề trên và nhiều chủ đề khác trong bộ sưu tập các hướng dẫn được gắn thẻ Tối ưu hóa Server của ta .
Các tin liên quan
