Panoramica sugli asincroni

Un processo asincrono è un processo o una funzione che non richiede l’interazione con l’utente. Può essere usato per eseguire un’attività “in background”, senza che l’utente debba aspettare che l’attività sia terminata.

  • Apex asincrono (@future Apex, batch Apex, queueable Apex, scheduled Apex)
  • Lavori API di massa
  • Rapporti programmati
  • Aggiornamenti del cruscotto

L’elaborazione asincrona offre una serie di vantaggi, tra cui:

  • Efficienza dell’utente – Far attendere un processo in esecuzione da molto tempo non è un uso efficiente del tempo dell’utente. L’elaborazione può essere eseguita in background e l’utente può vedere i risultati a suo piacimento.
  • Efficienza delle risorse – Ogni istanza di Salesforce dispone di un insieme finito di risorse. In condizioni di carico normali, queste risorse possono essere gestite per processi asincroni, che in genere consentono un’elaborazione più rapida delle richieste.
  • Scalabilità – Consentendo l’esecuzione asincrona di alcune funzioni di Force.com, le risorse possono essere gestite e scalate rapidamente. Ciò consente all’istanza di Salesforce di gestire un maggior numero di lavori dei clienti utilizzando l’elaborazione parallela.

L’elaborazione asincrona di Force.com fa del suo meglio per completare le richieste il più rapidamente possibile, tuttavia non vi è alcuna garanzia sui tempi di attesa o di elaborazione.

Panoramica sul processo asincrono

Sfide per il processo asincrono multitenant

  • Garantire l’equità dell’elaborazione – Assicurarsi che ogni cliente abbia una possibilità equa di accedere alle risorse di elaborazione.
  •  

    Garantire le capacità transazionali – Assicurare che i guasti alle apparecchiature o al software consentano di continuare l’elaborazione a capacità ridotta e che le richieste siano mantenute fino al completamento.

Salesforce.com utilizza un framework di elaborazione asincrona basato su code. Questo framework viene utilizzato per gestire le richieste asincrone di più organizzazioni all’interno di ciascuna istanza. Il ciclo di vita della richiesta è composto da tre parti:

  • Enqueue – La richiesta viene inserita nella coda. Può trattarsi di una richiesta Apex batch, di una richiesta Apex @future o di molte altre. L’applicazione Salesforce mette in coda le richieste insieme ai dati appropriati per elaborare la richiesta.
  • Persistence- La richiesta messa in coda viene memorizzata. Le richieste vengono memorizzate in uno storage persistente per il recupero dei guasti e per fornire funzionalità transazionali.
  • Dequeue – La richiesta in coda viene rimossa dalla coda ed elaborata. La gestione delle transazioni avviene in questa fase per garantire che i messaggi non vadano persi in caso di errore di elaborazione.

Elaborazione asincrona in azione

Ogni richiesta viene elaborata da un gestore. Il gestore è il codice che esegue le funzioni per uno specifico tipo di richiesta.

Gli handler vengono eseguiti da thread worker su ciascuno dei server applicativi che compongono un’istanza. Ogni application server supporta un numero finito di thread. Ogni thread può eseguire qualsiasi tipo di gestore e Salesforce determina quanti thread sono disponibili per elaborare le richieste per un determinato tipo di richiesta.

Nel diagramma, i lavori di lunga durata sono rappresentati da caselle più grandi.

Gestione equa delle richieste

Una singola organizzazione potrebbe mettere in coda 250.000 richieste @future Apex in 24 ore, a seconda del tipo di licenza Salesforce.

Se un’organizzazione aggiunge un numero elevato di richieste alla coda, potrebbe impedire ad altri clienti di accedere ai thread dei lavoratori. Per evitare ciò, il framework di accodamento implementa un controllo del flusso che impedisce a un singolo cliente di utilizzare tutti i thread disponibili.

Quando un thread worker è disponibile per elaborare una richiesta, il framework di accodamento determina se il numero massimo di thread worker (determinato dal gestore) è utilizzato da una singola organizzazione. In tal caso, il framework “sbircia” nella coda per vedere se altre organizzazioni hanno richieste in attesa. L’insieme di richieste è chiamato peek set ed è limitato a un numero fisso di richieste in testa alla coda (attualmente impostato a 2.000 richieste).

Ad esempio, si supponga che l’organizzazione 1 crei 13 richieste @future che sono in testa e adiacenti nella coda, come mostrato nel diagramma seguente:

L’organizzazione 2 aggiunge due richieste @future alla coda:

Step di processo

  1. 12 thread prenderanno in carico le prime 12 richieste dall’organizzazione 1.
  2. Il 13° thread non elaborerà una richiesta dell’organizzazione 1, sebbene sia la successiva in coda. Questo perché l’organizzazione 1 ha esaurito il numero di thread assegnati. Questa richiesta rimarrà nella coda nella sua posizione attuale fino a quando non si renderà disponibile uno dei 12 thread. Questa richiesta è ritardata.
  3. Il framework cercherà le richieste di altre organizzazioni all’interno dell’insieme di 15 richieste. Troverà la prima richiesta @future dell’organizzazione 2 e inizierà a elaborare questa richiesta, saltando la 13esima richiesta dell’organizzazione 1.

Anche in questo caso, si ipotizza che 12 thread stiano elaborando le richieste dell’organizzazione 1. Questa volta, l’organizzazione 1 ha 15 richieste rimanenti nella coda e l’organizzazione 2 ha due richieste nella coda, come mostrato in questo diagramma:

Poiché tutte le richieste del peek set provengono da un’unica organizzazione (organizzazione 1), queste 15 richieste verranno spostate in fondo alla coda con un ritardo specifico. Questo ritardo è chiamato ritardo esteso.

Il ritardo è diverso per ogni messaggio. Ad esempio, per le richieste @future, il ritardo è di 5 minuti. Ciò significa che devono trascorrere almeno 5 minuti prima che queste richieste siano eleggibili per l’elaborazione.

Quando le richieste ritardate diventano eleggibili per l’elaborazione, è possibile che queste richieste vengano gestite dal controllo di flusso e che vengano nuovamente spostate in fondo alla coda e ritardate.

Conservazione delle risorse

L’elaborazione asincrona in Force.com è molto importante, ma ha una priorità inferiore rispetto all’interazione in tempo reale tramite browser e API. I gestori di messaggi vengono eseguiti sugli stessi server applicativi che elaborano le richieste interattive ed è possibile che l’elaborazione asincrona o l’aumento dell’uso interattivo possano causare un improvviso aumento dell’utilizzo delle risorse di calcolo.

Migliori pratiche per Apex asincrono

 Future Apex

Ogni invocazione di @future aggiunge una richiesta alla coda asincrona. I modelli di progettazione che aggiungono un gran numero di richieste @future in un breve periodo di tempo dovrebbero essere evitati, a meno che non sia assolutamente necessario. Le migliori pratiche includono:

  • Evitare di aggiungere un gran numero di metodi @future alla coda asincrona, se possibile. Se nella coda sono presenti più di 2.000 richieste non elaborate da una singola organizzazione, ogni ulteriore richiesta dalla stessa organizzazione sarà ritardata mentre la coda gestisce le richieste di altre organizzazioni.
  • Assicurarsi che le richieste @future vengano eseguite il più velocemente possibile. Per garantire un’esecuzione rapida dei lavori batch, ridurre al minimo i tempi di chiamata del servizio Web e ottimizzare le query utilizzate nei metodi @future. Più lunga è l’esecuzione del metodo @future, più è probabile che le altre richieste in coda vengano ritardate quando c’è un gran numero di richieste in coda.
  • Testare i metodi @future in scala. Se possibile, eseguire i test utilizzando un ambiente che generi il numero massimo di metodi @future che ci si aspetta di gestire. Questo aiuterà a determinare se si verificheranno ritardi.
  • Considerare l’uso di Apex batch invece dei metodi @future per elaborare un gran numero di record in modo asincrono. Questo sarà più efficiente rispetto alla creazione di una richiesta @future per ogni record.

Il tempo di ritardo esteso è di 5 minuti.

Batch Apex

Assicurarsi che il processo Batch Apex venga eseguito nel modo più efficiente possibile e ridurre al minimo i lotti inviati in una sola volta. Come le richieste @future, il batch Apex deve essere eseguito il più velocemente possibile. Le migliori pratiche includono:

  • Evitare di aggiungere un gran numero di richieste batch Apex alla coda asincrona, se possibile. Se nella coda sono presenti più di 2.000 richieste non elaborate di una singola organizzazione, qualsiasi altra richiesta della stessa organizzazione verrà ritardata mentre la coda gestisce le richieste di altre organizzazioni.
  • Ottimizzare qualsiasi query SOQL per raccogliere i record da eseguire il più rapidamente possibile.
  • Ridurre al minimo i tempi di chiamata dei servizi Web, se utilizzati.

Il ritardo prolungato non è applicabile al batch Apex.

Migliori pratiche per l’API Bulk

L’API Bulk consente di creare lavori e batch per caricare grandi volumi di dati in modo asincrono. I batch dell’API Bulk vengono aggiunti alla coda asincrona. Se vengono inviati troppi batch in una sola volta, questi possono essere soggetti al controllo di flusso; pertanto, se possibile, ridurre al minimo il numero di batch.

Se nella coda sono presenti più di 2.000 richieste non elaborate da una singola organizzazione, qualsiasi altra richiesta proveniente dalla stessa organizzazione verrà ritardata mentre la coda gestisce le richieste di altre organizzazioni. Ridurre al minimo il numero di lotti inviati contemporaneamente per garantire che i lotti non vengano ritardati nella coda.

 

 

 

Fonte: tradotto da sites.google

Share:

administrator