Ciągłe odpytywanie serwera przez JavaScript - dobry pomysł?

Question

Mam małą witrynę internetową, która ma około 5-10 administratorów. Ustawiłem to, aby monitorować, co robi każdy administrator (dodawanie przedmiotów, usuwanie przedmiotów itp.). Miałem listę w naszym panelu administracyjnym, która pokazuje 10 ostatnich czynności wykonywanych przez administrację zbiorową. Dzisiaj postanowiłem dokonać samoczynnej aktualizacji co 30 sekund.

Moje pytanie jest proste: czy jest jakiś problem z tym? Podczas każdego żądania wywołuję niewielki fragment tekstu, a żądanie prawdopodobnie działa tylko na 3 lub 4 komputerach jednocześnie (co odzwierciedla liczbę zalogowanych administratorów współdziałających).

$(document).ready(function(){ 
    setInterval("activity()", 30000); 
    }); 

    function activity() { 
    $("#recent_activity").load("../home/login #recent_activity .data"); 
    } 

Tworzy następujące (lub podobne - tylko z 10 rzędami) przy każdym żądaniu.

<table> 
    <tbody> 
    <tr> 
     <td><p>jsampson</p></td> 
     <td><p>logged out</p></td> 
     <td><p>28 minutes 27 seconds ago</p></td> 
    </tr> 
    <tr> 
     <td><p>jdoe</p></td> 
     <td><p>logged in</p></td> 
     <td><p>29 minutes 45 seconds ago</p></td> 
    </tr> 
    </tbody> 
</table> 

Answer 1

3-4 użytkowników co 30 sekund to niewiele. Nawet 300 użytkowników w takim tempie nie byłoby wcale.

Możesz sprawdzić na te pytania:

• Should I use Ajax Push or Pull
• Simple Long Polling Example Code

Ty może cache to za dobrze, a byłoby wskazane zwłaszcza jeśli zapytanie do generowanie strony jest ciężkie obliczeniowo, ale oczywiście weź pod uwagę, jakiego rodzaju opóźnienie chcesz w najnowszych treściach wyświetlane.

Answer 2

Nie sądzę, że stanowiłoby to problem.

Answer 3

Nie, nie powinno być żadnych problemów. Robię to samo w odstępach 1-minutowych dla systemu powiadomień, który napisałem na portalu intranetowym mojej firmy. Każdy serwer powinien być w stanie sobie z tym poradzić, szczerze.

To naprawdę nie jest gorszy (w rzeczywistości znacznie lepszy) niż na przykład, powiedzmy, odświeżanie ich przeglądarki co 30 sekund ... Biorąc pod uwagę znacznie mniejszy transfer danych, byłoby to prawdopodobnie coś w skali 10-20 razy lepiej niż odświeżanie ... lub, o tej samej przepustowości odświeżania raz na 5-10 minut. :-)

Answer 4

Powinieneś buforować to i aktualizować pamięć podręczną co 30 sekund.

Answer 5

Nie ma problemu w mojej opinii. Witryny działające na znacznie większą skalę (na przykład Betfair) używają setek połączeń xhr na minutę dla każdego podłączonego klienta. Oczywiście mają znacznie większą infrastrukturę sprzętową, ale przeglądarka radzi sobie świetnie.

Mam witryny, które używają mniejszych interwałów i skalują się do kilkuset równoczesnych użytkowników działających z serwera Sinlge.

Answer 6

Powiedziałbym, że zależy to przede wszystkim od tego, jak drogie jest to zapytanie.

Mimo że jest to teraz niewielka liczba użytkowników, czy tak będzie zawsze?

Answer 7

Jak zauważył altCognito - ruch internetowy z tego nie będzie stanowił problemu.

Jedyne, co chciałbym sprawdzić, to czy ładowanie bazy danych wymagane do tego będzie problemem. To znaczy. jeśli jest on zasilany przez zapytanie, które może trochę potrwać, spowoduje to problemy. Jeśli tak jest, zalecam dodanie buforowania do danych lub utrzymywanie danych w pamięci zamiast w DB (tylko ładowanie z DB przy uruchamianiu i dodawanie rzeczy do tej listy w pamięci serwera jako zdarzają się).

Answer 8

Odważ to przeciwko alternatywie. Jeśli każdy użytkownik odświeżał stronę co 30 sekund, ładowanie całej strony, ilość przetwarzania po stronie serwera i generowanego ruchu byłaby znacznie większa niż odświeżenie "interesujących części".

Właśnie z tego powstał AJAX.

Answer 9

Czy widziałeś podgląd Google Wave ...? Dla tak niewielkiej liczby nie stanowi to problemu, zwłaszcza że administratorzy o tym wiedzą. (To nie jest tak, że obciążasz procesor lub połączenie z internetem.)

Answer 10

Wielu użytkowników nie obniży twojego serwera.

Jeśli jesteś naprawdę zaniepokojony wydajność, dam ci radę: 2

• Użyj JSON wysyłania danych do klienta, będzie on lżejszy niż sformatowany HTML.

• Użyj ustalonej daty dla danych historycznych i obliczyć względny czas na kliencie, pozwoli to na buforowanie danych historii.

  {"user":"jsampson","action":"logged out","date":"20090622T170822"}

Answer 11

Tak, to nie powinno być problemu w najmniejszym stopniu.

W związku z tym, jeśli niepokoi Cię ilość danych, które zostały odesłane, zawsze możesz sprawić, że połączenie odeśle prostą flagę JEŻELI są nowe dane, a następnie pobierz dane, jeśli tak jest.

Ale tak, przy takiej liczbie użytkowników nie powinno być żadnych problemów. Niestandardowa tablica informacyjna na RoR, której często używam, wykorzystuje podobną technikę, aby sprawdzić, czy wątki zostały zaktualizowane podczas czytania, i że ponad 100 użytkowników uderza w nią jednocześnie bez żadnego problemu.

Answer 12

Istnieje kilka różnych sposobów emulowania serwera poprzez HTTP. Takie techniki mają ostatnio wymyślną nazwę: Comet.

Jeśli konfiguracja serwera zezwala na uruchamianie skryptów w nieskończoność, można użyć elementu iframe do zaimplementowania panelu i użycia transferów z fragmentami (na przykład za pomocą PHP flush()) w celu utworzenia trwałego połączenia HTTP. Takie rozwiązanie powinno mieć najmniejszy narzut, jeśli odstęp między kolejnymi wiadomościami jest krótki. W przypadku długich odstępów preferowane jest odpytywanie po stronie klienta, ponieważ nie trzeba utrzymywać połączenia TCP.

Answer 13

Myślę, że to, co zrobiłeś, jest świetne.

Gdybym robił ten projekt, zacznę od tego, co masz i dodaj zdarzenie setTimeout(), aby zwiększyć wyświetlanie minut/sekund w każdej sekundzie.

Użytkownicy będą postrzegać wyświetlacz jako działający w czasie rzeczywistym i prawdopodobnie nigdy nie odświeżą strony.

Niebezpieczeństwo związane z aktualizowaniem tylko co 30 sekund powoduje, że niektórzy ludzie odruchowo odświeżają komunikat "najnowsze" za każdym razem, gdy zwracają na nie uwagę.

Należy również rozważyć specjalne znakowanie wszystkiego w czasie krótszym niż pięć minut. I kodowanie kolorami zalogowanymi i wylogowanymi. Ludzie będą łatwiej "skanować", ponieważ będą mogli wybrać zmiany bez czytania całego tekstu.