Tôi không có hệ quy chiếu nào về cái được coi là "nhanh"; Tôi luôn tự hỏi điều này nhưng chưa bao giờ tìm được câu trả lời thẳng thắn ...
Câu trả lời:
OpenStreetMap dường như có 10-20 mỗi giây
Wikipedia dường như là 30000 đến 70000 mỗi giây trải rộng trên 300 máy chủ (100 đến 200 yêu cầu mỗi giây trên mỗi máy, hầu hết trong số đó là bộ nhớ đệm)
Geograph nhận được 7000 hình ảnh mỗi tuần (1 hình ảnh tải lên mỗi 95 giây)
Không chắc ai đó vẫn quan tâm, nhưng thông tin này đã được đăng trên Twitter (và ở đây nữa ):
Số liệu thống kê
- Hơn 350.000 người dùng. Những con số thực tế vẫn như mọi khi, rất siêu siêu tuyệt mật.
- 600 yêu cầu mỗi giây.
- Trung bình 200-300 kết nối mỗi giây. Tăng tốc lên 800 kết nối mỗi giây.
- MySQL xử lý 2.400 yêu cầu mỗi giây.
- 180 phiên bản Rails. Sử dụng Mongrel làm máy chủ "web".
- 1 Máy chủ MySQL (một hộp lõi 8 lớn) và 1 máy chủ. Slave chỉ được đọc để thống kê và báo cáo.
- Hơn 30 quy trình xử lý các công việc lặt vặt.
- 8 mặt trời X4100s.
- Xử lý một yêu cầu trong 200 mili giây trong Rails.
- Thời gian trung bình dành cho cơ sở dữ liệu là 50-100 mili giây.
- Hơn 16 GB bộ nhớ đệm.
Khi tôi đi đến bảng điều khiển của máy chủ web của mình, mở phpMyAdmin và nhấp vào "Hiển thị thông tin thời gian chạy MySQL", tôi nhận được:
Máy chủ MySQL này đã chạy trong 53 ngày, 15 giờ, 28 phút và 53 giây. Nó bắt đầu vào ngày 24 tháng 10 năm 2008 lúc 04:03 sáng.
Thống kê truy vấn: Kể từ khi khởi động, 3.444.378.344 truy vấn đã được gửi đến máy chủ.
Tổng 3,444 M
mỗi giờ 2,68 M
mỗi phút 44,59 k
mỗi giây 743,13
Đó là trung bình 743 truy vấn mySQL mỗi giây trong 53 ngày qua!
Tôi không biết về bạn, nhưng với tôi thì nhanh quá! Rất nhanh!!
cá nhân, tôi thích cả phân tích được thực hiện mọi lúc .... yêu cầu / giây và thời gian / yêu cầu trung bình và thích nhìn thấy thời gian yêu cầu tối đa cũng như trên đó. rất dễ dàng để lật nếu bạn có 61 yêu cầu / giây, sau đó bạn có thể chỉ cần lật nó đến 1000ms / 61 yêu cầu.
Để trả lời câu hỏi của bạn, chúng tôi đã tự mình thực hiện một bài kiểm tra tải rất lớn và nhận thấy phạm vi trên các phần cứng amazon khác nhau mà chúng tôi sử dụng (giá trị tốt nhất là cpu trung bình 32 bit khi nó giảm xuống $$ / event / giây) và yêu cầu / giây của chúng tôi dao động từ 29 yêu cầu / giây / nút đến 150 yêu cầu / giây / nút.
Cung cấp phần cứng tốt hơn tất nhiên sẽ cho kết quả tốt hơn nhưng không phải là ROI tốt nhất. Dù sao, bài đăng này cũng rất tuyệt vì tôi đang tìm kiếm một số điểm tương đồng để xem các số của tôi ở đâu trong sân bóng và chia sẻ của tôi cũng như trong trường hợp ai đó đang tìm kiếm. Của tôi hoàn toàn được tải cao nhất có thể.
LƯU Ý: nhờ phân tích yêu cầu / giây (không phải ms / yêu cầu), chúng tôi đã tìm thấy một vấn đề lớn của linux mà chúng tôi đang cố gắng giải quyết trong đó linux (chúng tôi đã thử nghiệm máy chủ trong C và java) đóng băng tất cả các cuộc gọi vào thư viện ổ cắm khi tải quá nhiều có vẻ rất kỳ quặc. Bài viết đầy đủ có thể được tìm thấy ở đây thực sự .... http://ubuntuforums.org/showthread.php?p=11202389
Chúng tôi vẫn đang cố gắng giải quyết vấn đề đó vì nó mang lại cho chúng tôi một mức tăng hiệu suất rất lớn trong đó thử nghiệm của chúng tôi tăng từ 2 phút 42 giây lên 1 phút 35 giây khi điều này được khắc phục, vì vậy chúng tôi thấy hiệu suất cải thiện 33% .... chưa kể, Cuộc tấn công DoS càng tồi tệ hơn khi những lần tạm dừng này kéo dài hơn để tất cả các cpu giảm xuống 0 và ngừng xử lý ... theo ý kiến của tôi, quá trình xử lý máy chủ nên tiếp tục khi đối mặt với DoS nhưng vì một số lý do, nó bị đóng băng thỉnh thoảng trong thời gian Dos đôi khi lên đến 30 giây !!!
BỔ SUNG: Chúng tôi phát hiện ra đó thực sự là một lỗi điều kiện cuộc đua jdk .... khó có thể cô lập trên các cụm lớn nhưng khi chúng tôi chạy 1 máy chủ 1 nút dữ liệu nhưng 10 trong số đó, chúng tôi có thể tạo lại nó mọi lúc và chỉ cần nhìn vào máy chủ / datanode nó xảy ra trên. Chuyển jdk sang bản phát hành trước đó đã khắc phục sự cố. Tôi tin rằng chúng tôi đã ở trên jdk1.6.0_26.
Đó là một dạng câu hỏi rất cởi mở.
Bạn đang hỏi 1. tải yêu cầu trung bình cho một ứng dụng sản xuất 2. điều gì được coi là nhanh
Những thứ này không liên quan đến nhau.
# Yêu cầu trung bình mỗi giây của bạn được xác định bởi
a. số lượng người dùng đồng thời
b. số lượng yêu cầu trang trung bình mà họ thực hiện mỗi giây
c. số lượng yêu cầu bổ sung (ví dụ: cuộc gọi ajax, v.v.)
Đối với những gì được coi là nhanh .. bạn có nghĩa là có bao nhiêu yêu cầu mà một trang web có thể thực hiện? Hoặc nếu một phần cứng được coi là nhanh nếu nó có thể xử lý xyz # yêu cầu mỗi giây?
Lưu ý rằng biểu đồ tỷ lệ truy cập sẽ là các mẫu hình sin với 'giờ cao điểm' có thể gấp 2 lần hoặc gấp 3 lần tỷ lệ bạn nhận được khi người dùng đang ngủ. (Có thể hữu ích khi bạn đang lên lịch cho các công việc xử lý hàng loạt hàng ngày diễn ra trên các máy chủ)
Bạn có thể thấy hiệu ứng ngay cả trên các trang web 'quốc tế' (đa ngôn ngữ, được bản địa hóa) như wikipedia
Bạn có thể tìm kiếm "phân tích hiệu ứng gạch chéo" để biết biểu đồ về những gì bạn sẽ thấy nếu một số khía cạnh của trang web đột nhiên trở nên phổ biến trong tin tức, ví dụ như biểu đồ này trên wiki .
Ứng dụng web tồn tại có xu hướng là những ứng dụng có thể tạo ra các trang tĩnh thay vì đưa mọi yêu cầu thông qua một ngôn ngữ xử lý.
Có một video xuất sắc (tôi nghĩ nó có thể có trên ted.com? Tôi nghĩ nó có thể do nhóm web flickr? Có ai đó biết liên kết không?) Với các ý tưởng về cách mở rộng trang web ngoài một máy chủ duy nhất, ví dụ như cách phân bổ các kết nối giữa sự kết hợp giữa các máy chủ chỉ đọc và đọc ghi để có được hiệu quả tốt nhất cho nhiều loại người dùng khác nhau.