Làm cách nào để tối ưu hóa ứng dụng dựa trên web với độ trễ do nhiều yêu cầu không đồng bộ trong nền?

Question

Tôi đang thiết kế một mô đun RIA dựa trên kiến ​​trúc MVC phía máy khách mỏng. Ngay bây giờ, Ứng dụng chỉ hoàn thành trong phạm vi 10% và do đó không quá muộn để kết hợp các thay đổi thiết kế.

Ứng dụng được thiết kế theo cách ban đầu nó tải với một dấu chân rất nhỏ và tùy thuộc vào hành động được thực hiện bởi người dùng, khối lượng lớn dữ liệu được tìm nạp không đồng bộ. Dữ liệu này có khả năng sẽ bao gồm cả dữ liệu được lưu trữ trong máy chủ của tôi cũng như dữ liệu từ các dịch vụ web của bên thứ ba bao gồm các dịch vụ mạng xã hội và blog.

Tuy nhiên những gì tôi quan tâm là, có thể nhiều yêu cầu ajax dữ liệu nặng chạy trong nền ngăn chặn trình duyệt không? Gần đây tôi đã quan sát thấy một số vấn đề về độ trễ nghiêm trọng trong một số dịch vụ tổng hợp nội dung xã hội và khi phân tích mã phía máy khách, tôi đã ngạc nhiên rằng dấu chân ứng dụng của phía máy khách khá nhỏ, trong phạm vi 300KB. Tuy nhiên, khi chạy ứng dụng rất thường xuyên trình duyệt (cả Firefox và IE) bị treo cổ và mất vài giây để phục hồi. Sau khi phân tích các yêu cầu không đồng bộ, nó xuất hiện rằng ứng dụng đã đồng thời tìm nạp nội dung người dùng từ gmail, facebook và twitter và đẩy chúng vào DOM và đang dùng quá nhiều tài nguyên bộ nhớ.

Thật tuyệt vời nếu ai đó có thể chỉ cho tôi một số nguyên tắc/phương pháp hay nhất để ngăn chặn các vấn đề như vậy. Nó sẽ được khuyến khích để viết một kịch bản wrapper tùy chỉnh tải nội dung trong nền tuần tự trong một thứ tự được xác định trước tầm quan trọng hơn là tải tất cả song song, mà cuối cùng có thể dẫn đến một số callbacks được thực hiện song song.

Mọi lời khuyên sẽ được đánh giá cao.

Answer 1

Một giải pháp, đây không phải là giải pháp sát thủ cho mọi trường hợp, nhưng một giải pháp là ủy quyền tổng hợp nội dung ở phía máy chủ chứ không phải tất cả trong trình duyệt cuối cùng.

Điều này có thể được thực hiện với ESIGates. Một trong số đó là Varnish-Esi nhưng không bao gồm toàn bộ ESI specification. This one (esigate.org) cũng là nguồn mở và có thể với mức độ phù hợp tốt hơn (chưa được kiểm tra). Hệ thống ESI có nghĩa là bố cục ứng dụng của bạn có thể là sự kết hợp của các khối khác nhau với chính sách bộ nhớ cache khác nhau (TTL) và các nhà cung cấp khác nhau. Máy chủ ESI sẽ mất một phần lưu lượng truy cập mà ban đầu bạn đã trục xuất đến trình duyệt cuối cùng, vì vậy, sẽ khiến bạn tốn nhiều băng thông hơn, nhưng ít nhất bạn sẽ nhận được kiểm soát nhiều hơn trên phần mềm này các trình duyệt khác nhau được khách hàng HTTP sử dụng.

Ít nhất nó có thể cải thiện chính sách lưu trữ dữ liệu không đồng bộ trên máy chủ của bạn và theo cách đó, nó có thể tăng thời gian phản hồi cho trình duyệt cuối cùng (thời gian phản hồi tốt hơn, ít công việc song song hơn).

Bây giờ ở phía brwoser, trong nhiệm kỳ của ưu tiên trên trang của bạn, bạn chắc chắn nên thiết lập các nội dung quan trọng nhất, một trong đó người dùng có thể bắt đầu để chơi với, là gì và chỉ là một 'trang trí '(tốt, điều này ngụ ý dịch vụ của bạn như một tỷ lệ thông tin/tiếng ồn tốt, nếu trang web của bạn không có gì để cung cấp ngoại trừ tập hợp mạng xã hội, bạn sẽ gặp vấn đề).

Tôi giả định rằng khi ứng dụng của bạn là một ứng dụng nhỏ tĩnh với rất nhiều dữ liệu được tải không đồng bộ, bạn đang sử dụng rất nhiều ajax và không thay đổi quá nhiều trang. Điều này có nghĩa là khi nội dung được tải, nó sẽ nằm trong trang trong một thời gian dài.

Vì vậy, có xã hội mạng & nội dung dịch vụ web khác trì hoãn và xích thay vì một tải song song lớn should'nt là một vấn đề. Có lẽ nó sẽ không có trong 15 giây đầu tiên, nhưng nếu nó ở lại trên trang trong 15 phút tiếp theo thì có thể không phải là vấn đề (nếu nội dung quan trọng nhất đã có, người dùng có thể sẽ không nhận thấy rằng nội dung trang trí không có sẵn). Một trong những IE6 (và đôi khi IE7) tip ở đây, sử dụng lệnh SetTimeouts() js ở khắp mọi nơi để buộc repaint của các trang, bạn sẽ thấy rằng nội dung có sẵn cho thấy nhanh hơn.

Mẹo cuối cùng, nếu bạn cần thực hiện một số kiểm tra ajax thông thường cho nội dung được cập nhật. Nếu bạn thực sự kiểm tra 10 nội dung mỗi phút, bạn sẽ luôn gặp vấn đề tải song song và hoạt động lớn, cùng vấn đề như trong lần tải đầu tiên, thường bạn có thể sử dụng 2 thứ để khắc phục sự cố đó, một là COMET familly long -kết nối HTTP tuyệt vời (vì vậy bạn có thể thay thế PUSH dữ liệu và/hoặc nhận phản hồi nhanh hơn, nhưng chỉ với máy chủ của bạn được điều chỉnh cho loại lưu lượng HTTP đó). Thứ hai là thêm yếu tố thời gian cho lần kiểm tra tiếp theo, để kiểm tra đầu tiên sau 1 phút, 2 phút tiếp theo, sau đó 3, 15, 25, v.v., cuối cùng bạn chỉ có séc mới mỗi giờ có lẽ. Và bạn có thể giảm độ trễ kiểm tra tiếp theo khi bạn phát hiện một số hoạt động từ người dùng (một số tương tác của người dùng). Điều này là do bạn có thể giả định rằng người dùng thực sự đang tìm kiếm dữ liệu mới chỉ khi anh ấy thực sự làm điều gì đó với trang của bạn. bạn sẽ lưu một số CPU người dùng và bạn cũng sẽ giúp tải máy chủ của mình.

Answer 2

Tôi cũng có độ trễ tải trang vì plugin Facebook/LinkedId/etc.

Giải pháp cho tôi là tải không đồng bộ JavaScript của bên thứ ba. Nó hoạt động không cho tất cả các dịch vụ web/widget nhưng đối với nhiều người trong số họ (Facebook "Like" nút, Twitter "tweet" nút, vv).

Ví dụ:

<div id="tweet"> 
    <a href="http://twitter.com/share" 
     class="twitter-share-button" 
     data-count="horizontal" 
    >Tweet</a> 
</div> 
<script type="text/javascript"> 
    $(function() { 
     $.getScript('http://platform.twitter.com/widgets.js'); 
    }); 
</script> 

Mã này sẽ làm cho nút "Tweet" sau khi trang (DOM) nạp.

Nhưng bạn nên kiểm tra trước nếu JavaScript của dịch vụ web được yêu cầu sử dụng document.write() hay không. Nếu có - bạn không thể làm gì ở đây, chỉ có thể tải đồng bộ hóa.