VietNetwork.Vn

Trước đây tôi đã thực hiện kiểm tra điểm chuẩn trên nhiều máy chủ web vào năm 2012 và đã có một số người yêu cầu tôi thực hiện lại các bài kiểm tra với các phiên bản máy chủ web mới hơn vì chắc chắn rất nhiều thứ đã thay đổi kể từ đó.

Ở đây, tôi sẽ thực hiện các điểm chuẩn so với các phiên bản mới nhất hiện tại của một số máy chủ web dựa trên Linux và sau đó so sánh chúng với nhau để biết được cái nào hoạt động tốt nhất trong khối lượng công việc tĩnh.

Trước tiên, tôi sẽ thảo luận về cách các bài kiểm tra được thiết lập và thực hiện trước khi chuyển sang phần kết quả.

1. Phần mềm đo điểm chuẩn

Một lần nữa, tôi đã sử dụng Weighttpd để thực hiện các bài kiểm tra điểm chuẩn thực tế, vì tôi nhận thấy rằng nó hoạt động tốt và chia tỷ lệ khá đẹp với nhiều luồng.

Khoảng thời gian này, tôi đã chạy weighttpd trên máy ảo của chính nó, trước đây tôi đã không làm điều này vì tôi muốn tránh ngăn xếp mạng để có được hiệu suất tuyệt đối tốt nhất có thể. Vấn đề với việc chạy weighttpd trên cùng một máy chủ đang chạy phần mềm máy chủ web là một lượng đáng kể tài nguyên CPU sẽ được sử dụng bởi chính thử nghiệm, do đó bị lấy đi khỏi máy chủ web.

Một lần nữa, weighttpd được chạy thông qua tập lệnh abc, về cơ bản tự động hóa quá trình kiểm tra cho tôi. Thay vì chạy hàng trăm lệnh weighttpd, tôi sử dụng tập lệnh này để tự động chuyển qua các mức tương tranh khác nhau.

weighttp -n 100000 -c [0-1000 step:10 rounds:3] -t 8 -k "http://x.x.x.x:80/index.html"
Trong đó -n là số lượng yêu cầu, trong trường hợp này, chúng tôi đang gửi 100.000 yêu cầu cho mọi cấp độ đồng thời của -c được chỉ định. Nhờ có ab.c, chúng tôi có thể chuyển từ 0 yêu cầu đồng thời lên đến 1.000 với gia số 10 lần một lần. Mỗi bài kiểm tra cũng được thực hiện 3 lần như quy định trong các vòng, bằng cách này, tôi có thể nhận được kết quả trung bình tốt hơn vì mỗi cấp độ đồng thời được chạy 3 lần. Do đó, tổng cộng mọi thử nghiệm đều dẫn đến khoảng 30.000.000 yêu cầu GET được gửi đến máy chủ web tại http://xxxx:80/index.html.

Cờ -t chỉ định số lượng luồng sẽ sử dụng, điều này được điều chỉnh từ 1, 2, 4 và 8 tùy thuộc vào số lượng lõi CPU được chỉ định cho máy chủ web cho mỗi lần kiểm tra. Cờ -k cũng được chỉ định khi chúng tôi đang sử dụng tính năng giữ nguyên.

2. Môi trường thử nghiệm

Để thực hiện các bài kiểm tra, tôi đã sử dụng hai máy ảo đang chạy trên VMware ESXi 5.5, vì vậy mặc dù có thể đạt được một lượng hiệu suất bổ sung cực kỳ nhỏ khi chạy trên kim loại trần, nhưng việc sử dụng các máy ảo cho phép tôi dễ dàng sửa đổi số lượng lõi CPU có sẵn khi thay đổi giữa các lần kiểm tra. Dù sao thì tôi cũng không cố gắng đạt được hiệu suất tuyệt đối tốt nhất, miễn là mỗi bài kiểm tra có thể so sánh được với những bài kiểm tra khác thì không sao và tôi có thể kiểm tra đầy đủ những gì mình đang theo đuổi.

Bản thân máy chủ vật lý đang chạy ESXi có hai ổ cắm CPU, mỗi ổ cắm có CPU Intel Xeon L5639 @ 2,13GHz (Turbo 2,7GHz), với tổng số 12 lõi CPU. Đây là phần cứng hoàn toàn khác với phần cứng tôi đã sử dụng cho các thử nghiệm của mình vào năm 2012, vì vậy vui lòng không so sánh trực tiếp số lượng yêu cầu mỗi giây với các biểu đồ cũ. Các số được cung cấp trong bài đăng này chỉ nên được so sánh ở đây trong bài đăng này vì mọi thứ được chạy trên cùng một phần cứng ở đây.

Cả máy ảo chạy kiểm tra weighttpd và máy ảo chạy phần mềm máy chủ web đều chạy CentOS 7.2 với nhân Linux 3.10.0-327.10.1.el7.x86_64 được cài đặt (cập nhật đầy đủ kể từ ngày 03/05/2016). Cả hai máy chủ đều có bộ nhớ 4GB và 20gb dung lượng ổ đĩa dựa trên SSD. Số lượng lõi CPU trên máy chủ web được điều chỉnh thành 1, 2, 4 và sau đó là 8.

3. Máy chủ web

Mặc dù máy chủ web VM có nhiều phần mềm máy chủ web khác nhau được cài đặt cùng một lúc, nhưng chỉ có một phần mềm thực sự chạy cùng một lúc và được liên kết với cổng 80 để thử nghiệm. Việc khởi động lại hệ thống được thực hiện sau mỗi lần kiểm tra vì tôi muốn đo chính xác bộ nhớ đã được sử dụng từ mỗi lần kiểm tra.

Các phiên bản máy chủ web được kiểm tra như sau, đây là các phiên bản được cập nhật mới nhất hiện tại khi thực hiện kiểm tra ngày 03/05/2016.

Cập nhật ngày 04/1/2016: Tôi đã kiểm tra lại OpenLiteSpeed, vì họ đã thực hiện một số sửa lỗi để phản hồi lại bài đăng này trong phiên bản 1.4.16.

Cập nhật ngày 04/09/2016: Tôi đã kiểm tra lại các phiên bản Nginx Stable và Mainline, sau một số trợ giúp từ Valentin Bartenev từ Nginx, người đã liên hệ với tôi trong các nhận xét bên dưới, tôi đã có thể giải quyết một số vấn đề lạ về hiệu suất mà tôi gặp phải ở các cấp độ lõi cpu cao hơn.

• Apache 2.4.6 (Prefork MPM)
• Nginx ổn định 1.8.1
• Dòng chính Nginx 1.9.13
• Cherokee 1.2.104
• Lighttpd 1.4.39
• OpenLiteSpeed 1.4.16
• Vecni 4.1.1

Điều quan trọng cần lưu ý là các máy chủ web này chỉ phục vụ khối lượng công việc tĩnh, đó là trang index.html 7 byte. Mục tiêu của thử nghiệm này là để biết được cách các máy chủ web hoạt động với tốc độ thô bằng cách cung cấp cùng một tệp. Tôi muốn thử nghiệm thêm trong tương lai đối với nội dung động chẳng hạn như PHP, hãy cho tôi biết nếu bạn muốn xem nội dung này.

Mặc dù Varnish được sử dụng để lưu vào bộ đệm chứ không phải là một máy chủ web chính thức, nhưng tôi nghĩ nó vẫn sẽ rất thú vị khi đưa vào. Bộ đệm Varnish đã được thử nghiệm với phần cuối Nginx 1.8.1 – điều này không thực sự quan trọng, vì sau yêu cầu đầu tiên, index.html sẽ được lấy từ bộ đệm Varnish.

Tất cả các máy chủ web đã được kích hoạt liên tục, với thời gian chờ duy trì hoạt động là 60 giây, với 1024 yêu cầu được phép cho mỗi kết nối duy trì hoạt động. Nếu có thể, các tệp cấu hình máy chủ web đã được sửa đổi để cải thiện hiệu suất, chẳng hạn như cài đặt 'server.max-worker' trong lighttpd để bằng với số lượng lõi CPU như khuyến nghị trong tài liệu. Ghi nhật ký truy cập cũng bị vô hiệu hóa để ngăn I/O đĩa không cần thiết và để ngăn đĩa đầy nhật ký.

4. Cấu hình máy chủ

Các điều chỉnh sau đã được thực hiện cho cả máy chủ thực hiện kiểm tra và máy chủ web để giúp tối đa hóa hiệu suất.

Tệp /etc/sysctl.conf đã được sửa đổi như bên dưới.

fs.file-max = 5000000
net.core.netdev_max_backlog = 400000
net.core.optmem_max = 10000000
net.core.rmem_default = 10000000
net.core.rmem_max = 10000000
net.core.somaxconn = 100000
net.core.wmem_default = 10000000
net.core.wmem_max = 10000000
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_congestion_control = bic
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_max_syn_backlog = 12000
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_mem = 30000000 30000000 30000000
net.ipv4.tcp_rmem = 30000000 30000000 30000000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_wmem = 30000000 30000000 30000000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
Tệp /etc/security/limits.conf đã được sửa đổi như bên dưới.

* soft nofile 10000
* hard nofile 10000
Những thay đổi này là cần thiết để ngăn chặn các giới hạn khác nhau bị ảnh hưởng, chẳng hạn như hết cổng TCP hoặc tệp đang mở. Điều quan trọng cần lưu ý là những giá trị này có thể không phải là giá trị bạn muốn sử dụng trong môi trường sản xuất, tôi đang sử dụng chúng để đạt được hiệu suất tốt nhất có thể từ máy chủ của mình và cũng để ngăn quá trình chạy thử nghiệm bị lỗi.

5. Kết quả điểm chuẩn

Bây giờ tất cả những điều đó đã được giải thích, đây là kết quả kiểm tra điểm chuẩn của tôi dưới dạng biểu đồ.

Điểm chuẩn máy chủ web 1 Lõi CPU:


Điểm chuẩn máy chủ web 2 lõi CPU:


Điểm chuẩn máy chủ web 4 lõi CPU:


Điểm chuẩn máy chủ web 8 lõi CPU:


Nói chung, Apache dường như vẫn hoạt động kém nhất như mong đợi, vì đây là trường hợp truyền thống. Với 1 lõi CPU, Nginx ổn định rõ ràng dẫn đầu, tiếp theo là OpenLiteSpeed cho đến điểm đồng thời 600, nơi nó bắt đầu giảm xuống và bị Nginx Mainline và Lighttpd vượt qua ở các mức đồng thời cao hơn này. Với hai lõi CPU dòng chính Nginx và ổn định là ngang nhau, tuy nhiên phiên bản ổn định dường như hoạt động tốt hơn ở các mức đồng thời cao hơn, với OpenLiteSpeed không quá xa phía sau và đứng ở vị trí thứ ba.

Với 4 lõi CPU, cả hai phiên bản Nginx và OpenLiteSpeed đều rất gần nhau cho đến khi đạt 500 điểm kết nối đồng thời với OpenLiteSpeed dẫn đầu một chút, tuy nhiên sau 500 điểm OpenLiteSpeed và Nginx Mainline giảm xuống một chút và có vẻ tương đương nhau trong khi Nginx Stable dẫn đầu. Ở 8 lõi CPU, đây là sự kết hợp khá chặt chẽ giữa OpenLiteSpeed, Nginx Stable/Mainline và Lighttpd. Cả bốn người trong số này đã hoàn thành bài kiểm tra của họ trong vòng 12 giây với nhau, thực sự rất gần. Nginx Mainline đứng đầu lúc 4:16, Nginx Stable đứng thứ hai lúc 4:21, OpenLiteSpeed đứng thứ ba lúc 4:26 và Lighttpd đứng thứ tư lúc 4:28.

Như chúng ta có thể thấy với những thay đổi gần đây đối với OpenLiteSpeed, nó chắc chắn đã được tối ưu hóa cho loại khối lượng công việc này vì nó hoạt động khá gần với Nginx, tốc độ về cơ bản đã tăng gấp đôi sau đó. Ngoài ra, có vẻ như Lighttpd hiện đang đánh bại Cherokee ổn định hơn so với khi tôi chạy các bài kiểm tra này trước đây. Phiên bản mới nhất của bộ đệm Varnish cũng hoạt động tốt hơn đáng kể dựa trên số lượng lõi CPU có sẵn nhiều hơn khi nó tăng lên trong mỗi thử nghiệm, từ điểm kém nhất gần như thứ hai với 1 lõi CPU lên điểm tốt thứ hai với 8 lõi CPU.

Trong các thử nghiệm ban đầu của mình, tôi gặp một số vấn đề kỳ lạ về hiệu suất với Nginx chỉ sử dụng khoảng 50% CPU ở số lượng lõi CPU 4 và 8, sau khi được Valentin Bartenev từ Nginx liên hệ và cung cấp một số đề xuất thay đổi cấu hình Nginx dường như hoạt động tốt hơn nhiều như có thể được nhìn thấy bởi nó xuất hiện đầu tiên trong mọi bài kiểm tra ở đây. Tôi nghĩ rằng hầu hết hiệu suất tăng lên là kết quả của việc loại bỏ "sendfile on;" từ cấu hình của tôi như được đề xuất, vì điều này không được sử dụng nhiều cho nội dung nhỏ và như đã đề cập, tôi đang sử dụng tệp HTML 7 byte. Các thay đổi được đề xuất khác giúp cải thiện hiệu suất bao gồm:

   accept_mutex off;
   open_file_cache  max=100;
   etag off;
   listen 80 deferred reuseport fastopen=512; #I only found this worked in Mainline.
Mặt khác, cấu hình Nginx là mặc định.

6. Sử dụng bộ nhớ

Vào cuối mỗi bài kiểm tra ngay trước khi điểm chuẩn hoàn thành, tôi đã ghi lại dung lượng bộ nhớ được sử dụng bằng lệnh 'free -m'. Tôi cũng đã lưu ý dung lượng bộ nhớ chỉ được sử dụng bởi hệ điều hành sau khi khởi động lại mới để chúng tôi có thể so sánh những gì các máy chủ web đang thực sự sử dụng. Kết quả được hiển thị trong biểu đồ bên dưới và dữ liệu bộ nhớ thô có thể được tìm thấy trong tệp văn bản này.


Như bạn có thể thấy, việc sử dụng bộ nhớ không nhiều lắm vì VM được chỉ định 4gb. Điều này nên được mong đợi với khối lượng công việc nhỏ và tĩnh như vậy. Mặc dù vậy, Apache và Varnish dường như sử dụng nhiều bộ nhớ hơn đáng kể so với các máy chủ web khác. Varnish được định cấu hình để sử dụng rõ ràng RAM cho bộ đệm, tuy nhiên, tệp index.html tĩnh chỉ có kích thước 7 byte. Khác với hai cái đó, những cái khác khá đồng đều khi so sánh.

7. Tổng thời gian đã thực hiện

Biểu đồ cuối cùng này chỉ hiển thị thời gian hoàn thành các bài kiểm tra ở định dạng giờ:phút:giây. Hãy ghi nhớ như đã đề cập trước đó, mỗi thử nghiệm sẽ dẫn đến khoảng 30.000.000 yêu cầu NHẬN cho trang index.html.


Dữ liệu thô từ biểu đồ này có thể được xem tại đây.

Ở đây chúng ta có thể thấy dễ dàng hơn rằng một số máy chủ web có khả năng mở rộng tốt hơn những máy chủ khác. Lấy ví dụ về Apache, với 1 lõi CPU, yêu cầu trung bình mỗi giây là 7.500, nhân đôi CPU có sẵn và yêu cầu mỗi giây tăng gấp đôi lên khoảng 15.000, nhân đôi CPU một lần nữa thành 4 lõi CPU và yêu cầu cũng tăng gấp đôi lên 30.000, gấp đôi một lần nữa với 8 lõi CPU và chúng tôi hiện có 60.000 yêu cầu mỗi giây.

Mặc dù hoạt động kém nhất về tổng thể, nhưng kết quả của Apache thực sự khá dễ đoán và có thể mở rộng. So sánh điều này với kết quả lõi CPU 4 và 8 của Cherokee, nơi có vẻ như thực sự tiết kiệm được rất ít thời gian khi tăng từ 4 lên 8 lõi. Mặt khác, Nginx có kết quả rất giống nhau trong thử nghiệm lõi 4 và 8 của tôi về tổng thời gian thực hiện, mặc dù thực hiện nhanh nhất nhưng tôi thấy điều thú vị là ở cấp độ này, các lõi bổ sung không giúp được gì nhiều, có thể điều chỉnh thêm cần thiết để có được hiệu suất tốt hơn ở đây.

Kết quả cho thấy rằng trong hầu hết các trường hợp, chỉ cần tăng CPU và điều chỉnh cấu hình một chút sẽ cung cấp mức tăng hiệu suất có thể mở rộng theo khối lượng công việc tĩnh.

Điều này có thể sẽ thay đổi khi có hơn 8 lõi CPU được thêm vào. Tôi đã bắt đầu thấy lợi nhuận giảm dần khi so sánh sự khác biệt giữa việc tăng từ 1 lên 2 lõi CPU so với việc tăng từ 4 lên 8 lõi CPU. Nhiều lõi hơn không phải lúc nào cũng tốt hơn trừ khi có các biện pháp tối ưu hóa để thực sự sử dụng nhiều tài nguyên hơn.

Mặc dù Apache có thể là máy chủ web được sử dụng rộng rãi nhất nhưng điều thú vị là nó vẫn đứng cuối trong hầu hết các thử nghiệm, nhưng lại sử dụng nhiều tài nguyên hơn. Tôi sẽ phải xem xét Lighttpd/OpenLiteSpeed nhiều hơn vì cả hai đều đã đưa ra một số kết quả thú vị ở đây và tôi chưa sử dụng chúng nhiều trước đây, đặc biệt là với số lượng lõi CPU cao hơn. Mặc dù Nginx đã giành chiến thắng nhưng tôi có một chút kinh nghiệm về điều này và đã sử dụng nó trước đây – đó là máy chủ web tôi đang sử dụng để phục vụ trang web này.

Tôi muốn biết liệu thông tin này có thay đổi máy chủ web mà bạn sử dụng hay không. Bạn thường sử dụng máy chủ web nào và tại sao?