Kiểm tra áp lực

Kết quả kiểm tra áp lực chịu ảnh hưởng bởi những yếu tố nào?

  • Độ trễ mạng từ máy kiểm tra đến máy chủ (khuyến nghị kiểm tra trong mạng nội bộ hoặc trên máy local)
  • Băng thông từ máy kiểm tra đến máy chủ (khuyến nghị kiểm tra trong mạng nội bộ hoặc trên máy local)
  • Có bật HTTP keep-alive hay không (khuyến nghị bật)
  • Số lượng đồng thời có đủ không (nếu kiểm tra từ bên ngoài, hãy cố gắng mở rộng số lượng đồng thời)
  • Số lượng tiến trình trên máy chủ có hợp lý không (số tiến trình cho dịch vụ helloworld nên bằng số CPU, số tiến trình cho dịch vụ cơ sở dữ liệu nên gấp bốn lần số CPU trở lên)
  • Hiệu suất của dịch vụ chính nó (ví dụ như có sử dụng cơ sở dữ liệu bên ngoài hay không)

HTTP keep-alive là gì?

Cơ chế HTTP Keep-Alive là một kỹ thuật được sử dụng để gửi nhiều yêu cầu và phản hồi HTTP trên một kết nối TCP duy nhất, nó có ảnh hưởng lớn đến kết quả kiểm tra hiệu suất, sau khi tắt keep-alive, QPS có thể giảm xuống gấp đôi.
Hiện nay, các trình duyệt đều mặc định bật keep-alive, tức là sau khi trình duyệt truy cập vào một địa chỉ http nào đó, nó sẽ tạm giữ kết nối mà không đóng, và tái sử dụng kết nối này cho lần yêu cầu tiếp theo, nhằm cải thiện hiệu suất.
Khuyến nghị bật keep-alive khi kiểm tra áp lực.
Ngoài ra, nếu không bật keep-alive khi kiểm tra, cổng địa phương của khách hàng sẽ nhanh chóng bị tiêu thụ bởi trạng thái timewait, và thể hiện ở chỗ tổng số yêu cầu vượt quá một số lượng nhất định (thường khoảng 28.000), sẽ xuất hiện các yêu cầu thất bại.

Làm thế nào để bật HTTP keep-alive khi kiểm tra áp lực?

Nếu sử dụng chương trình ab để kiểm tra, cần thêm tham số -k, ví dụ ab -n100000 -c200 -k http://127.0.0.1:8787/.
apipost cần phải trả lại header gzip để có thể bật keep-alive (lỗi của apipost, xem bên dưới).
Các chương trình kiểm tra áp lực khác thường sẽ mặc định bật.

Tại sao QPS khi kiểm tra từ bên ngoài lại rất thấp?

Độ trễ bên ngoài lớn dẫn đến QPS rất thấp, đó là hiện tượng bình thường. Ví dụ, QPS khi kiểm tra trang baidu có thể chỉ vài chục.
Khuyến nghị kiểm tra trong mạng nội bộ hoặc trên máy local, để loại bỏ ảnh hưởng của độ trễ mạng.
Nếu buộc phải kiểm tra từ bên ngoài, có thể tăng số lượng đồng thời để tăng thông lượng (cần đảm bảo băng thông đủ).

Tại sao hiệu suất giảm sau khi qua proxy nginx?

Chạy nginx cần tiêu tốn tài nguyên hệ thống. Đồng thời, việc giao tiếp giữa nginx và webman cũng cần tiêu tốn một lượng tài nguyên nhất định.
Tuy nhiên, tài nguyên hệ thống là có hạn, webman không thể lấy tất cả tài nguyên hệ thống, vì vậy, hiệu suất toàn bộ hệ thống có thể bị giảm xuống là hiện tượng bình thường.
Để giảm thiểu ảnh hưởng hiệu suất do proxy nginx, có thể xem xét tắt nhật ký nginx (access_log off;),
mở keep-alive giữa nginx và webman, tham khảo nginx代理.

Ngoài ra, https và http so với nhau sẽ tiêu tốn nhiều tài nguyên hơn, vì https cần thực hiện một quá trình bắt tay SSL/TLS, mã hóa và giải mã dữ liệu, kích thước gói tăng lên sẽ chiếm nhiều băng thông hơn, tất cả điều này có thể dẫn đến giảm hiệu suất.
Khi kiểm tra áp lực sử dụng liên kết ngắn (không bật HTTP keep-alive), mỗi lần yêu cầu đều cần thêm quá trình bắt tay SSL/TLS, hiệu suất sẽ giảm đáng kể. Khuyến nghị khi kiểm tra https hãy bật HTTP keep-alive.

Làm thế nào để biết hệ thống đã đạt đến giới hạn hiệu suất?

Thông thường, khi CPU đạt 100% có nghĩa là hiệu suất hệ thống đã đạt đến giới hạn. Nếu CPU còn trống nghĩa là chưa đến giới hạn, lúc này có thể tăng số lượng đồng thời để nâng cao QPS.
Nếu tăng số lượng đồng thời không thể cải thiện QPS, có thể là do số lượng tiến trình webman không đủ, hãy tăng thêm số tiến trình webman. Nếu vẫn không cải thiện, hãy xem xét băng thông có đủ không.

Tại sao kết quả kiểm tra áp lực của tôi cho thấy hiệu suất webman thấp hơn framework gin của go?

Dữ liệu kiểm tra từ techempower cho thấy webman có chỉ số cao hơn gin gần gấp đôi trong tất cả các chỉ số như văn bản thuần, truy vấn cơ sở dữ liệu, cập nhật cơ sở dữ liệu.
Nếu kết quả của bạn khác, có thể là do bạn đã sử dụng ORM trong webman mang lại tổn thất hiệu suất khá lớn, có thể thử so sánh webman + PDO nguyên bản với gin + SQL nguyên bản.

Sử dụng ORM trong webman sẽ làm giảm hiệu suất bao nhiêu?

Dưới đây là một bộ dữ liệu kiểm tra

Môi trường
Máy chủ Alibaba Cloud 4 nhân 4G, cơ sở dữ liệu MySQL cục bộ, truy vấn ngẫu nhiên một bản ghi từ 100.000 bản ghi và trả về json, kiểm tra trên máy local.

Nếu sử dụng PDO nguyên bản
webman QPS là 17.800

Nếu sử dụng Db::table() của laravel
QPS của webman giảm xuống 9.400

Nếu sử dụng Model của laravel
webman QPS giảm xuống 7.200

Kết quả của thinkORM tương tự, không có sự khác biệt lớn.

Ghi chú
Mặc dù việc sử dụng ORM sẽ làm giảm hiệu suất, nhưng đối với 99% các dịch vụ thì hiệu suất đã vượt quá yêu cầu, nếu bạn chính xác là 1% thì cũng có thể dễ dàng giải quyết bằng cách tăng CPU hoặc máy chủ.
Chúng ta nên tìm ra một điểm cân bằng trong nhiều chỉ số như hiệu suất phát triển, khả năng bảo trì, hiệu suất, thay vì chỉ theo đuổi hiệu suất mà thôi.

Tại sao QPS khi kiểm tra bằng apipost lại rất thấp?

Mô-đun kiểm tra áp lực của apipost có lỗi, nếu máy chủ không trả về header gzip thì sẽ không giữ được keep-alive, dẫn đến hiệu suất giảm đáng kể.
Giải pháp là trả về dữ liệu đã nén và thêm header gzip, ví dụ

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

Ngoài ra, trong một số trường hợp, apipost không thể tạo ra áp lực thỏa đáng, điều này thể hiện rõ ở chỗ cùng một số lượng đồng thời, sử dụng apipost sẽ thấp hơn khoảng 50% QPS so với ab.
Khuyến nghị nên sử dụng ab, wrk hoặc các phần mềm kiểm tra áp lực chuyên nghiệp khác thay vì apipost.

Cài đặt số lượng tiến trình hợp lý

webman mặc định mở 4 lần số tiến trình CPU. Trên thực tế, với dịch vụ kiểm tra áp lực helloworld không có I/O mạng, số tiến trình nên bằng số lõi CPU để đạt hiệu suất tối ưu, vì chúng sẽ giảm thiểu chi phí chuyển đổi tiến trình.
Nếu là dịch vụ I/O chặn như cơ sở dữ liệu, redis, số tiến trình có thể được đặt từ 3-8 lần số CPU, vì lúc này cần nhiều tiến trình hơn để nâng cao độ đồng thời, trong khi chi phí chuyển đổi tiến trình sẽ trở nên gần như không đáng kể so với I/O chặn.

Một số phạm vi tham khảo cho kiểm tra áp lực

Máy chủ đám mây 4 nhân 4G 16 tiến trình Kiểm tra trong mạng local/nội bộ

- Bật keep-alive Không bật keep-alive
hello world 80.000-160.000 QPS 10.000-30.000 QPS
Truy vấn đơn trong cơ sở dữ liệu 10.000-20.000 QPS 10.000 QPS

Dữ liệu kiểm tra áp lực từ bên thứ ba techempower

Ví dụ lệnh kiểm tra áp lực

ab

# 100000 yêu cầu 200 đồng thời Bật keep-alive
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 yêu cầu 200 đồng thời Không bật keep-alive
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 đồng thời kiểm tra trong 10 giây Bật keep-alive (mặc định)
wrk -c 200 -d 10s http://example.com