Scaling ứng dụng trò chuyện - bỏ phiếu ngắn so với bỏ phiếu dài (AJAX, PHP)

Question

tôi chạy một trang web mà người dùng có thể trò chuyện với nhau thông qua trình duyệt (nghĩ Facebook chat). Cách tốt nhất để xử lý tương tác trực tiếp là gì? (Ngay bây giờ tôi có một cuộc thăm dò sẽ mỗi 30 giây để cập nhật người dùng trực tuyến và tin nhắn mới đến, và một cuộc thăm dò đi trên các trang trò chuyện mỗi giây để nhận thư mới.)

Những điều tôi đã xem xét:

• Ổ cắm web HTML5: không sử dụng vì nó không hoạt động trên tất cả các trình duyệt (chỉ có chrome).
• Ổ cắm flash: không sử dụng điều này vì tôi muốn cuối cùng hỗ trợ web di động.

Hiện tại, tôi đang sử dụng tính năng bỏ phiếu ngắn vì tôi không biết cách tính năng bỏ phiếu dài AJAX có thể mở rộng được. Tôi đang chạy một máy chủ VPS từ servint ngay bây giờ (chạy apache). Tôi có nên sử dụng bỏ phiếu dài hoặc bỏ phiếu ngắn? Tôi không cần thời gian phản hồi hoàn toàn ngay lập tức (chỉ "đủ tốt" cho một ứng dụng trò chuyện). Việc bỏ phiếu ngắn này có thường xuyên với vài trăm nghìn người dùng sẽ giết máy chủ của tôi không? Làm cách nào để chia tỷ lệ này, vui lòng trợ giúp!

Answer 1

Một vài lưu ý:

• Polling mỗi giây là quá mức cần thiết. Ứng dụng sẽ vẫn cảm thấy rất nhạy cảm với một vài giây chậm trễ giữa các lần kiểm tra.
• Để lưu lưu lượng truy cập và tốc độ của lưu lượng truy cập của db, hãy xem xét sử dụng bộ nhớ cache trong bộ nhớ để lưu trữ thư chưa được gửi. Bạn vẫn có thể duy trì các thông báo tới db, bộ đệm trong bộ nhớ sẽ đơn giản được sử dụng cho các truy vấn cho các thư mới để tránh các truy vấn tới db mỗi x giây của mỗi người dùng.
• Hết thời gian trò chuyện của người dùng sau x giây không hoạt động để ngừng bỏ phiếu cho máy chủ của bạn. Điều này đảm bảo ai đó để mở cửa sổ sẽ không tiếp tục tạo lưu lượng truy cập. Cung cấp một đơn giản "Vẫn còn đó? Tiếp tục trò chuyện." liên kết cho các phiên hết thời gian chờ và cảnh báo người dùng trước thời gian chờ để họ có thể kéo dài thời gian chờ.
• Tôi khuyên bạn nên bắt đầu với việc bỏ phiếu hơn là bỏ phiếu/ổ cắm/sao chổi dài. Bỏ phiếu rất đơn giản để xây dựng và hỗ trợ và có khả năng sẽ có quy mô tốt trong ngắn hạn. Nếu bạn nhận được rất nhiều lưu lượng truy cập, bạn có thể ném phần cứng và cân bằng tải tại sự cố để mở rộng quy mô. Toàn bộ trang web được dựa trên việc bỏ phiếu - bỏ phiếu chắc chắn nhất là quy mô. Có một điểm mà sự phức tạp của các lựa chọn thay thế như sao chổi/long polling/etc có ý nghĩa, nhưng bạn cần rất nhiều lưu lượng truy cập trước khi thời gian phát triển thêm/phức tạp là hợp lý.

Answer 2

Đây là điều mà tất cả mọi người đã làm một lần khi một thời gian trước khi sự ra đời của cometd và nodejs.

Vấn đề như tôi nhìn thấy nó là yêu cầu PHP trên Apache là rất tốn kém. Nếu ứng dụng trò chuyện của bạn kiểm tra thư mỗi giây bạn sẽ thấy mình trong tình huống mà Apache không có đủ tài nguyên để trả lời các yêu cầu. Khu vực khác tôi nghĩ cần cải thiện là cải thiện ngữ cảnh của ứng dụng trò chuyện của bạn.

Tại sao nó cập nhật mỗi giây nếu không truy xuất thư mới? Điều gì sẽ xảy ra nếu không có tin nhắn?

Một số kỹ thuật bạn có thể sử dụng;

• Cung cấp thiết bị đầu cuối nhẹ cho các khách hàng của bạn có một số bối cảnh về phiên chat, là một thông điệp mới chờ giải quyết, bao nhiêu tin nhắn, vv Các khách hàng có thể đáp ứng này bằng cách cập nhật ngay lập tức hay không nếu có Không có thư mới. Điểm cuối này có thể cung cấp một đối tượng json đơn giản thông qua yêu cầu http. Bạn được đảm bảo rằng thông báo trạng thái này sẽ có kích thước cố định và nếu phản hồi của trạng thái không thay đổi, bạn có thể phân rã nó. Xem tin nhắn tiếp theo.

• Một phân rã đơn giản trong cuộc thăm dò javascript của bạn, nếu khách hàng nhận được phản hồi tương tự từ máy chủ một vài lần liên tiếp, bạn có thể tăng cuộc thăm dò theo thời gian đã đặt, hiện tại bạn đã nói là mỗi giây. Nếu bạn đã làm điều này bạn sẽ tăng lên mỗi 2,4,6,8,10 giây. Ngay sau khi phản hồi từ máy chủ thay đổi, bạn đặt lại phân rã.

Một số tối ưu cần xem xét;

• Sử dụng bộ nhớ cache Opcode PHP như APC.

• Set một thời gian chờ thấp trên tất cả các yêu cầu, bạn không muốn bất kỳ yêu cầu để treo máy chủ của bạn.

• Tối ưu hóa mã PHP của bạn, làm cho nó nạc và nhanh chóng.

• Chạy một số xét nghiệm tải để xem những gì giới hạn của bạn đang có.

• Hiệu suất điểm chuẩn thường xuyên để đảm bảo các ứng dụng của bạn nhanh hơn.

• Kiểm tra nhật ký apache để biết các dấu hiệu câu chuyện về sức khỏe tổng thể của ứng dụng và thời gian phản hồi.

Khi mở rộng quy mô, hãy thêm máy chủ mới và sử dụng bộ cân bằng tải để phân phối yêu cầu. Tôi đã sử dụng Varnish và HAProxy với thành công lớn, thiết lập chúng cũng không phức tạp.

Answer 3

Nếu tôi là bạn, tôi muốn chọn thư viện sử dụng ổ cắm web html5 chưa rơi vào ổ flash nếu html5 không khả dụng, trình duyệt rơi qua vết nứt phải là phút.

Ngoài ra, bạn nên bỏ qua php hoặc bổ sung nó bằng một máy chủ socket luồng được viết bằng python hoặc ruby ​​với em-websocket.