Xem một số hoạt động nặng của website ăn tài nguyên VPS thế nào? • Kiến càng

Cấu hình VPS:

DigitalOcean: 2GB RAM, 1AMD CPU, 50GB Disk, vị trí máy chủ ở Singapore
Control Panel: ServerPilot x Ubuntu 18.04 (LTS) x64

Website thử nghiệm kiencang.net:

1200 bài viết
2GB dữ liệu
Gần 20 plugin phổ thông

Nhưng mà câu hỏi đầu tiên: tôi cần biết các hoạt động chiếm nhiều tài nguyên máy chủ để làm gì?

Nó có nhiều công dụng:

Biết được tại sao website lại chậm, gồm cả kiểu chậm bất chợt.
Tiết kiệm tiền nhờ tận dụng được một cách khéo léo số lượng website host tại cùng một nơi (vì cái này cần tìm điểm cân bằng, nếu bạn để dư nhiều tài nguyên thì phí tiền, còn nếu tham dùng nhiều tài nguyên thì website sẽ chậm, thậm chí là hay gián đoạn).

Mục lục

#1. Tạo file backup bằng UpdraftPlus

UpdraftPlus là một trong các plugin backup thường được dùng trên nhiều website, cài đặt phổ thông là dùng phiên bản miễn phí kết nối với Google Drive.

Khi tôi tiến hành backup website nó mất khoảng gần 4 phút để hoàn thành (21h38′ đến 21h42′).

Dưới đây là các thống kê của VPS do DigitalOcean ghi lại:

mức sử dụng của CPU — CPU từ mức sử dụng 4% tăng lên mức 37% trong khoảng 2 phút, sau đó giữ nguyên trong 1 phút, và giảm 3% trong phút cuối, và mất khoảng 7 phút để trở lại trạng thái ban đầu là 4%

—

Memory tăng không đáng kể trong thời gian backup — Memory có ghi nhận tăng trong thời gian backup, nhưng không đáng kể, từ 42% lên 46%.

—

Sự biến thiên của Disk I/O — Disk I/O tăng trong khoảng thời gian backup, với write lên đến gần 50MB/s khi đạt đỉnh, còn read là gần 20MB/s

Sử dụng ổ đĩa — Trong khoảng thời gian backup, UpdraftPlus lưu dữ liệu cục bộ tại DO, sau khi đẩy lên Cloud của Google, thì nó cũng xóa luôn.

Băng thông sử dụng — Đây là băng thông output, nó bắt đầu tăng từ 21h40 (sau khi đã đóng gói xong file để đẩy lên cloud), kết thúc vào 21h50.

—

Trong một lần test khác, CPU lẫn RAM đều tăng cao hơn (dữ liệu website gần như không thay đổi):

Một trong những cách để giảm thiểu hoạt động nặng của backup lên website là bạn chọn khung giờ cụ thể để hoạt động backup diễn ra.

#2. Xuất file bằng All in one WP migration

All in one WP migration cũng là một trong các plugin rất hay được sử dụng trong quá trình chuyển hosting.

Chúng ta sẽ xem quá trình tổng hợp thành một file duy nhất của nó có tạo ra hiệu ứng khác với UpdraftPlus không (UpdraftPlus thì phân làm 5 loại file khác nhau: media, database, plugin, theme, other).

Kết quả cho thấy thao tác tổng hợp file của All in one WP migration diễn ra rất nhanh, chỉ trong vòng một phút nó đã tạo thành file tổng hợp duy nhất và cho phép tải xuống rồi.

Việc sử dụng tài nguyên của AioWPm cũng nhẹ nhàng hơn:

Sử dụng CPU của Cll in one WP migration — Nó chỉ dùng hết chưa tới 20% CPU trong thời gian đỉnh, nhìn sang bên tay trái đó chính là của UpdraftPlus

—

Memory trong quá trình sử dụng All in one WP migration — Memory thì gần như không có dấu hiệu tác động nào

—

Disk IO của All in one WP migration — Read và Write gần tương đương nhau (chưa đến 20MB/s). Write thấp hơn đáng kể so với UdraftPlus. Read sau đó kéo dài hơn 10 phút do quá trình tải file về máy tính cá nhân

—

Băng thông của All in one WP migration — Nó kéo dài hơn vì tốc độ tải về máy tính tại nhà không thể cao như việc trao đổi dữ liệu trực tiếp giữa DO và Google Drive.

Disk usage của All in one WP migration — Không có gì đặc biệt, All in one WP migration không tự xóa file, khi xóa dung lượng ổ đĩa sử dụng trở về trạng thái ban đầu

#3. Cài một bản WordPress trắng

Bandwidth, Disk usage, Memory không có dấu hiệu biến thiên gì đáng kể.

CPU tăng khoảng 8%, từ 6 – 7% lên 15%:

CPU tăng 10% khi cài một bản WP trắng — CPU tăng từ 6% lên 15%

Disk I/O khi cài trang WP trắng — Read khoảng 1.3 MB/s, Write khoảng 2.2 MB/s

#4. Khôi phục nguyên vẹn lại website 2GB (kiencang.net) trên trang demo

Dùng plugin All in one WP migration để khôi phục lại website y như trường hợp chuyển hosting. Cái này tôi dự đoán sẽ ăn tài nguyên hơn so với quá trình tạo file backup, nhưng cứ phải kiểm tra thì mới chắc được. Chúng ta cùng xem.

A. Trước hết là quá trình up file .wpress lên:

quá trình up file cũng làm CPU tăng đáng kể — Quá trình up file lên đủ khiến CPU đạt đỉnh ở mức 34%. Cao hơn quá trình xuất file.

RAM không có gì suy chuyển đáng chú ý. Disk Usage tăng theo dung lượng tăng thêm.

Disk I/O chậm rãi hơn quá trình xuất file.

B. Bung file, khôi phục website hoàn chỉnh

Quá trình bung file, khôi phục diễn ra rất nhanh, chỉ khoảng 1 phút.

CPU đạt đỉnh ở mốc 55%:

—

Lần đầu tiên thấy memory tăng từ 44 lên 64%:

—

Còn đây là Disk I/O:

Disk usage sau khi khôi phục xong thì xóa dữ liệu cũ nên không có gì đáng chú ý.

Bandwidth không có trao đổi gì trong giai đoạn này.

Sơ kết: khôi phục website so với các hoạt động khác ăn tài nguyên hơn đáng kể ở cả hai thông số quan trọng là CPU và RAM.

#5. Thực hiện một số thao tác với database bằng plugin Better Search Replace

Plugin Better Search Replace là plugin rất hay được dùng khi chuyển hosting, gộp trang web, hoặc tách website. Nó can thiệp vào cơ sở dữ liệu của website để thay thế dữ liệu cũ không còn phù hợp. Ví dụ như các thay thế http bằng https, thay thế tên miền cũ bằng tên miền mới.

A. Tìm kiếm

Khi thực hiện một số tìm kiếm, với việc tìm tất cả các bảng dữ liệu, với từ khóa kiencang.net vài lần (với một số biến thể) nó cho thấy CPU tăng lên từ khoảng 2% lên 32%

thực hiện tìm kiếm với plugin Better Search Replace

Memory không có biến đổi gì.

B. Thực hiện tìm kiếm và cập nhật dữ liệu lớn

Chưa có điều kiện kiểm tra.

#6. Dùng plugin Broken Link Checker để kiểm tra liên kết gãy trên toàn website

Plugin Broken Link Checker cũng có thể xem là plugin cần tài nguyên tương đối lớn. Chúng ta sẽ thử bật nó lên với một vài cài đặt xem nó “nhai” CPU thế nào?

Dường như Broken Link Checker được thiết kế khá tốt để không làm tốn tài nguyên quá nhiều. Mặc dù trong setting tôi chủ động nâng cho phép sử dụng 49% tài nguyên thay vì mặc định 25% thì nó cũng không chiếm dụng quá nhiều.

Broken Link Checker không ăn nhiều CPU như tưởng tượng

Ngoại trừ lúc đầu khi phải dò tất cả các liên kết hiện có trên website (8078 liên kết duy nhất trong 17120 liên kết) thì CPU tăng lên gần 27%, và Disk I/O phần Write tăng lên hơn 2MB/s thì sau đó nó đã hoạt động ổn định với CPU quanh mốc 7 – 10%

#7. Purge cache sau đó thử quét toàn bộ website bằng phần mềm Screaming Frog

Screaming Frog là phần mềm rất mạnh trong cộng đồng SEO. Khi dùng nó để quét toàn bộ website vừa mới purge cache xong, nó có thể khiến cho việc tăng sử dụng tài nguyên lên cao đáng chú ý:

CPU tăng nhanh trong hoạt động tạo trước cache — CPU tăng nhanh từ mốc “ổn định” 4%, và có lúc đạt đỉnh gần 97%, điều này chứng tỏ hoạt động tạo trước cache ăn tài nguyên đáng kể, nhưng thời gian tăng cao này không lâu, chỉ tầm một phút, sau đó phần lớn thời gian dao động quanh mức 40%.

Memory tăng không đáng kể — Memory có tăng nhưng không nhiều, từ 43% lên 50%.

Bandwidth không lớn — Bandwidth output đạt đỉnh ở mức gần 500kb/s. Con số này không lớn phần nhiều là do CDN lo phần tài nguyên tĩnh rồi. Giá trị này rõ ràng là không ăn thua gì so với hoạt động backup hoặc khôi phục website.

Kết luận

Qua các thử nghiệm nhỏ và hẵn còn thô sơ ở trên, chúng ta có thể thấy là, trong hầu hết các hoạt động nặng thì CPU bị ảnh hưởng nhiều nhất. RAM bị ảnh hưởng không nhiều, ngoại trừ hoạt động bung file khi khôi phục dữ liệu thì thấy tăng đáng kể.

DISK I/O và Bandwidth bị ảnh hưởng mạnh trong hoạt động backup và khôi phục dữ liệu, điều này là dễ hiểu khi nó phải trao đổi dữ liệu với bên ngoài và bung hoặc gom file của toàn bộ website.

Bandwidth không phải là vấn đề lo lắng với VPS như DigitalOcean, nó có tốc độ trao đổi dữ liệu rất tốt, thường 20 – 30Mb/s, và có thể đạt đến 100MB/s tối đa.

Nếu như website của chúng ta không có các hoạt động nặng thì cấu hình hosting sẽ rất nhẹ nhàng, nhưng thực tế rất khó có chuyện đó. Cấu hình cao nhằm đáp ứng cho các hoạt động ăn nhiều tài nguyên, khi đó nó đẩy các thông số hoạt động lên đỉnh, mà nếu không đáp ứng được sẽ bị downtime.

Rõ ràng, dù chúng ta không hoàn toàn tránh được các hoạt động nặng, nhưng chúng ta vẫn có khả năng giảm tần số các hoạt động đó xuống, điển hình là với các hoạt động lặp đi lặp lại như backup. Hoặc chúng ta dùng sẵn các dịch vụ của nhà cung cấp thay vì tự triển khai để giảm ảnh hưởng đến việc chạm vào ngưỡng tối đa của hosting.

Với các hoạt động hiếm khi xảy ra, như chuyển hosting, sẽ xảy ra một thực tế là một hosting nhỏ có thể không đáp ứng được với tác vụ chuyển host theo cách thông thường (ví dụ bằng plugin) nhưng vẫn đủ thông số cho tất cả các hoạt động khác của website. Điều đó dẫn đến việc, đôi khi chúng ta nâng thông số hosting chỉ để chuyển host, sau đó hạ nó xuống nhằm tiết kiệm chi phí, vì lúc này nó vẫn hoàn toàn ổn với thông số nhỏ hơn nhiều.