Czy długo trwa polling w Google App Engine?

Question

Potrzebuję aplikacji, która często wymaga odpytywania serwera, ale GAE ma ograniczenia dotyczące żądań, więc wiele wniosków może być bardzo kosztownych. Czy możliwe jest użycie długiego sondowania i sprawdzenie, czy żądania oczekują na maksimum 30 sekund na zmiany?

Answer 1

Google AppEngine ma nową funkcję kanału API, z tym masz się possibility to build a good realtime application.

Innym rozwiązaniem jest użycie trzeciej części komety, takiej jak mochiweb lub skręconej ze wzorem iframe.

Klient1, czeka na zdarzenie:

client1 --Iframe Pattern--> Erlang/Mochiweb(HttpLongPolling): 

Klient2, wysyłając wiadomość:

client2 --XhrIo--> AppEngine --UrlFetch--> Erlang/Mochiweb 

Aby korzystać mochiweb z komety wzór, Richard Jones napisał dobrą temat (na google: Richard Jones A Million-user Comet Application).

Answer 2

Nie sądzę, że długie głosowanie jest możliwe. Domyślny limit czasu żądania dla Google Appengine wynosi 30 sekund. W przypadku długiego sondowania, jeśli wygenerowanie wiadomości trwa dłużej niż 30 sekund, oznacza to, że nie udało się. Prawdopodobnie lepiej jest używać krótkiego sondowania.

Innym podejściem jest "symulowanie" długiego sondowania z limitem 30 sekund. Aby to zrobić, jeśli wiadomość nie dotrze w ciągu, powiedzmy 20 sekund, serwer może wysłać wiadomość "token" zamiast zwykłej wiadomości, wymagając, aby klient ją zużył i ponownie się połączył.

Wydaje się feature request (i jego zaakceptowane) w Google AppEngine za długi odpytywania

Answer 3

Próbowaliśmy wdrożyć rozwiązanie Comet-like long-polling na App Engine, z różnymi wynikami.

def wait_for_update(request, blob): 
    """ 
    Wait for blob update, if wait option specified in query string. 
    Otherwise, return 304 Not Modified. 
    """ 
    wait = request.GET.get('wait', '') 
    if not wait.isdigit(): 
     return blob 
    start = time.time() 
    deadline = start + int(wait) 
    original_sha1 = blob.sha1 
    try: 
     while time.time() < deadline: 
      # Sleep one or two seconds. 
      elapsed = time.time() - start 
      time.sleep(1 if elapsed < 7 else 2) 
      # Try to read updated blob from memcache. 
      logging.info("Checking memcache for blob update after %.1fs", 
         elapsed) 
      blob = Blob.cache_get_by_key_name(request.key_name) 
      # Detect changes. 
      if blob is None or blob.sha1 != original_sha1: 
       break 
    except DeadlineExceededError: 
     logging.info("Caught DeadlineExceededError after %.1fs", 
        time.time() - start) 
    return blob 

Problem, który widzę, polega na tym, że żądania po długim głosowaniu są seryjizowane (synchronizowane) za żądaniem długo odpytywania. Mogę spojrzeć na ślad w Chrome i zobaczyć oś czasu podobną do tej:

1. Prośba o wysłanie 1. GET (niezmodyfikowany) blob (poczekaj, aż zmieniony).
2. Żądanie 2 wysłane. Zmodyfikuj obiekt typu blob.
3. Po pełnym limicie czasu żądanie 1 powraca (dane niezmodyfikowane).
4. Żądanie 2 zostaje przetworzone na serwerze i zwraca sukces.

Użyłem Wireshark i Chrome/linii czasu, aby potwierdzić, że wysyłam zapytanie o modyfikację do serwera na osobnym połączeniu TCP z long-polling. Tak więc snychronizacja musi się odbywać na serwerze produkcyjnym App Engine. Google nie dokumentuje tych szczegółów zachowania serwera, o ile wiem.

Myślę, że czekanie na kanał API to najlepsza nadzieja na uzyskanie dobrego zachowania w czasie rzeczywistym z App Engine.