Evita la latenza durante i sondaggi relativi alle attività

L'API GetActivityTask è stata progettata per fornire un taskToken un'unica volta. Se un taskToken viene rimosso durante la comunicazione con un lavoratore di attività, un numero di richieste di GetActivityTask può rimanere bloccato per 60 secondi in attesa di risposta finché non si verifica un timeout del GetActivityTask.

Se hai solo un numero ridotto di poll in attesa di risposta, è possibile che tutte le richieste si accodino alla richiesta bloccata e si arrestino. Tuttavia, se hai un gran numero di sondaggi in sospeso per ogni attività Amazon Resource Name (ARN) e una certa percentuale delle tue richieste è bloccata in attesa, ce ne saranno molte altre che possono ancora ottenere taskToken un risultato e iniziare a essere elaborate.

Per i sistemi di produzione, consigliamo almeno 100 poll aperti per ARN di attività in ogni momento. Se un poll si blocca e una parte di quei poll vi si accoda, rimangono ancora molte altre richieste che otterranno un taskToken per elaborare il lavoro mentre la richiesta di GetActivityTask è bloccata.

Per evitare questo tipo di problemi di latenza durante il polling dei task:

• Implementa i tuoi poller come thread separati dal lavoro nella tua implementazione del lavoratore di attività.

• Fai in modo di avere almeno 100 poll aperti per ARN di attività in ogni momento.

  Nota

  Il ridimensionamento a 100 poll aperti per ARN può essere costoso. Ad esempio, il polling di 100 funzioni Lambda per ARN è 100 volte più costoso rispetto a una singola funzione Lambda con 100 thread di polling. Per ridurre la latenza e minimizzare i costi, utilizza un linguaggio che dispone di I/O asincrono e implementa più thread di polling per lavoratore. Per vedere un esempio di lavoratore di attività in cui i thread dei poller sono distinti dai thread del lavoro, consultare Esempio di lavoratore di attività in Ruby.

Per ulteriori informazioni sulle attività e sui lavoratori di attività, consultare Attività.