Jak zoptymalizować aplikację opartą na sieci Web przed opóźnieniem ze względu na wiele asynchronicznych żądań w tle?

Question

Projektuję modułową aplikację RIA opartą na architekturze MVC po stronie klienta cienkiego serwera. Obecnie aplikacja jest kompletna tylko w zakresie 10% i jako taka nie jest za późno na wprowadzenie zmian w projekcie.

Aplikacja została zaprojektowana w taki sposób, że początkowo ładuje się przy bardzo małej powierzchni, a w zależności od czynności wykonanej przez użytkownika duże ilości danych są pobierane asynchronicznie. Te dane mogą obejmować zarówno dane przechowywane na moich serwerach, jak i dane z zewnętrznych usług internetowych, w tym serwisy społecznościowe i usługi mikroblogowania.

Jednak to, co mnie niepokoi, to czy jest możliwe, że wiele ciężkich żądań ajaxów działających w tle blokuje przeglądarkę? Niedawno zauważyłem poważne problemy z opóźnieniami w niektórych usługach agregacji treści społecznościowych i po analizie kodu po stronie klienta zaskoczyło mnie, że ślad po stronie klienta był niewielki, w granicach 300 KB. Jednak podczas uruchamiania aplikacji bardzo często przeglądarka (zarówno Firefox, jak i IE) zawieszała się i trwała kilka sekund, aby odzyskać. Po przeanalizowaniu asymetrycznych żądań okazało się, że aplikacja pobierała jednocześnie zawartość użytkownika z Gmaila, Facebooka i Twittera i przesyłając je do DOM i pobierała zbyt dużo zasobów pamięci.

Byłoby wspaniale, gdyby ktoś mógł wskazać mi pewne wskazówki/najlepsze praktyki, aby zapobiec takim problemom. Byłoby wskazane napisanie niestandardowego skryptu owijającego, który ładuje zawartość w tle sekwencyjnie we wcześniej ustalonej kolejności ważności, zamiast ładować je wszystkie równolegle, co może w końcu doprowadzić do kilku wywołań zwrotnych równolegle.

Każda rada byłaby wysoko ceniona.

Answer 1

Jedno rozwiązanie, cóż, nie jest to rozwiązanie typu "killer" dla wszystkich przypadków, ale jednym z rozwiązań jest delegowanie agregacji treści po stronie serwera, a nie w ostatecznej przeglądarce.

Można to zrobić za pomocą ESIGates. Jednym z nich jest Varnish-Esi, ale nie obejmuje całego ESI specification. This one (esigate.org) jest również open source i może z lepszym zasięgiem (jeszcze nie testowane). System ESI oznacza, że ​​układ aplikacji może być kombinacją różnych bloków z różnymi zasadami pamięci podręcznej (TTL) i różnymi dostawcami. Serwer ESI weźmie część ruchu, który został pierwotnie wyeksportowany do końcowej przeglądarki, więc ta będzie Cię kosztować o wiele więcej przepustowości, ale przynajmniej uzyskasz więcej kontroli na tym oprogramowaniu niż na różne przeglądarki używane przez klientów HTTP.

Przynajmniej może może poprawić politykę buforowania asynchronicznych ładowań danych na serwerze, w ten sposób może przyspieszyć czas reakcji dla przeglądarki końcowej (lepszy czas reakcji, mniej pracy równoległej).

Teraz na stronie brwoser, w perspektywie priorytetu na swojej stronie należy z pewnością ustalić, co jest najważniejszą treść, który użytkownik może uruchomić się bawić, a co jest jedynie "dekoracji "(cóż, to oznacza, że ​​twoja usługa jest dobrym wskaźnikiem informacyjnym/szumem, jeśli twoja strona internetowa jako nic do dostarczenia, z wyjątkiem agregacji sieci społecznościowych, dostaniesz problemy).

Zakładam, że ponieważ twoja aplikacja jest małą, statyczną aplikacją z wieloma załadowanymi asynchronicznie danymi, używasz wielu ajaxów i nie zmieniasz zbyt wiele stron. Oznacza to, że po wczytaniu treści będzie ona umieszczona na stronie przez długi czas.

Więc o społecznej sieciami & zawartość innych usług internetowych opóźniony i przykuty zamiast dużego obciążenia równoległego should'nt być problemem. Może nie będzie tego w pierwszych 15 latach, ale jeśli pozostanie na stronie przez następne 15 minut, to może nie jest to problem (jeśli najważniejsza treść już tam jest, użytkownik może nawet nie zauważy, że zawartość ozdobna nie było dostępne). Jedna wskazówka na temat IE6 (i czasami IE7) tutaj, użyj poleceń js wszędzie, aby wymazać odświeżanie stron, zobaczysz, że dostępna zawartość wyświetla się szybciej.

Ostatnia wskazówka, jeśli chcesz zrobić regularne sprawdzanie ajaxów pod kątem zaktualizowanej zawartości. Jeśli naprawdę sprawisz, że teses sprawdzą co 10 minut co minutę, zawsze będziesz mieć problemy z równoległym ładowaniem i dużą aktywnością, ten sam problem co przy początkowym obciążeniu, zwykle możesz użyć 2 rzeczy, aby rozwiązać ten problem, jeden jest COMET rodzinnie długi - uruchamianie połączeń HTTP (abyś mógł zamiast tego pobierać dane PUSH i/lub uzyskiwać szybsze odpowiedzi, ale tylko z serwerem dostrojonym dla tego rodzaju ruchu HTTP). Druga polega na dodaniu współczynnika czasu dla następnych kontroli, tak aby pierwsze sprawdzenie nastąpiło po 1 minucie, następne 2 minuty, potem 3, 15, 25 itd., Na końcu masz nową kontrolę tylko co godzinę może. Możesz także zmniejszyć opóźnienie czeku, gdy wykryjesz aktywność użytkownika (interakcja użytkownika). Jest tak, ponieważ możesz założyć, że użytkownik naprawdę szuka nowych danych tylko wtedy, gdy naprawdę robi coś ze swoją stroną. zaoszczędzisz trochę procesora użytkownika, a także pomożesz załadować serwer.

Answer 2

Miałem również opóźnienie ładowania strony z powodu wtyczek Facebook/LinkedId/etc.

Rozwiązaniem dla mnie jest asynchroniczne ładowanie JavaScript strony trzeciej. Działa to nie dla każdej usługi internetowej/widgetu, ale dla wielu z nich (przycisk "Lubię to" na Facebooku, przycisk Twitter "tweet" itp.).

przykład:

<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> 

Kod ten spowoduje, przycisk "Tweet" po stronie (DOM) załadowany.

Ale powinieneś najpierw sprawdzić, czy JavaScript żądanej usługi internetowej używa document.write() czy nie. Jeśli tak - nie możesz nic tutaj zrobić, możliwe jest tylko ładowanie synchroniczne.