May mắn thay, nó thường không có nghĩa là như vậy.
Biến còn thiếu trong phương trình của bạn là cách cơ sở dữ liệu của bạn và máy chủ ứng dụng của bạn và bất kỳ thứ gì khác trong ngăn xếp của bạn xử lý đồng thời .
Để minh họa điều này một cách chặt chẽ từ quan điểm của MySQL, tôi đã viết một chương trình khách thử nghiệm thiết lập một số lượng cố định các kết nối đến máy chủ MySQL, mỗi kết nối trong chuỗi riêng của nó (và do đó, có thể đưa ra một truy vấn đến máy chủ cùng một lúc) .
Khi tất cả các chuỗi đã báo hiệu lại rằng chúng đã được kết nối, một thông báo sẽ được gửi đến tất cả chúng cùng một lúc, để gửi truy vấn của họ.
Khi mỗi luồng nhận được tín hiệu "đi", nó sẽ xem xét thời gian hệ thống hiện tại, sau đó gửi truy vấn đến máy chủ. Khi nhận được phản hồi, nó sẽ xem xét lại thời gian của hệ thống, sau đó gửi tất cả thông tin trở lại luồng chính, so sánh thời gian và tạo kết quả bên dưới.
Chương trình được viết theo cách không tính thời gian cần thiết để thiết lập các kết nối với máy chủ, vì trong một ứng dụng hoạt động tốt, các kết nối sẽ có thể sử dụng lại được.
Truy vấn là SELECT SQL_NO_CACHE COUNT(1) FROM ... (một bảng InnoDB với khoảng 500 hàng trong đó).
threads 1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads 2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads 4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads 8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841
Thời gian tính bằng giây. Tối thiểu / tối đa / trung bình là thời gian tốt nhất / kém nhất / trung bình được quan sát khi chạy cùng một truy vấn. Ở mức đồng thời là 64, bạn nhận thấy trường hợp tốt nhất không khác nhiều so với trường hợp tốt nhất chỉ có 1 truy vấn. Nhưng lợi ích lớn nhất ở đây là cột tổng thời gian chạy. Giá trị đó là sự khác biệt về thời gian kể từ khi luồng đầu tiên gửi truy vấn của nó (tất cả chúng đều gửi truy vấn về cơ bản cùng một lúc, nhưng "chính xác" cùng một thời điểm là không thể vì tôi không có máy 64 lõi để chạy tập lệnh kiểm tra bật) đến khi luồng cuối cùng nhận được phản hồi của nó.
Quan sát:tin tốt là 64 truy vấn mất trung bình 0,005586 giây chắc chắn không yêu cầu 64 * 0,005586 giây =0,357504 giây để thực thi ... nó thậm chí không yêu cầu 64 * 0,001089 (thời gian tốt nhất) =0,069696 Tất cả trong số các truy vấn đó được bắt đầu và kết thúc trong vòng 0,019841 giây ... hoặc chỉ khoảng 28,5% thời gian về mặt lý thuyết để chúng chạy lần lượt.
Tất nhiên, tin xấu là thời gian thực thi trung bình của truy vấn này ở mức đồng thời 64 cao gấp hơn 5 lần so với thời gian nó chỉ chạy một lần ... và trường hợp xấu nhất là gần gấp 14 lần. Nhưng điều đó vẫn tốt hơn nhiều so với phép ngoại suy tuyến tính từ thời gian thực thi một truy vấn sẽ đề xuất.
Tuy nhiên, mọi thứ không mở rộng vô thời hạn. Như bạn có thể thấy, hiệu suất giảm dần theo đồng thời và tại một thời điểm nào đó, nó sẽ xuống dốc - có thể là khá nhanh - khi chúng tôi đạt được bất kỳ nút thắt cổ chai nào xảy ra trước. Số lượng bảng, bản chất của các truy vấn, bất kỳ khóa nào gặp phải, tất cả đều góp phần vào cách máy chủ hoạt động dưới các tải đồng thời, cũng như hiệu suất của bộ nhớ của bạn, kích thước, hiệu suất và kiến trúc, của bộ nhớ hệ thống và nội bộ của MySQL - một số trong số đó có thể được điều chỉnh và một số trong số đó không thể.
Nhưng tất nhiên, cơ sở dữ liệu không phải là yếu tố duy nhất. Cách máy chủ ứng dụng xử lý các yêu cầu đồng thời có thể là một phần quan trọng khác trong hiệu suất của bạn khi tải, đôi khi ở mức độ lớn hơn cơ sở dữ liệu và đôi khi ít hơn.
Một ẩn số lớn từ điểm chuẩn của bạn là cơ sở dữ liệu đã dành bao nhiêu thời gian để trả lời các truy vấn, bao nhiêu thời gian được máy chủ ứng dụng sử dụng để thực hiện nghiệp vụ logic và bao nhiêu thời gian được sử dụng cho mã hiển thị kết quả trang thành HTML.
