How to handle priority¶
Supponiamo di avere un applicazione di tipo e-commerce che abbia al suo interno queste funzionalità.
- invio di un messaggio email di double-option (per la verifica dell’indirizzo email prima dell’acquisto).
- invio di una email di conferma acquisto.
- invio di una email di follow-up agli utenti che non hanno completato l’acquisto dopo 7 giorni.
In tutti e tre i casi si tratta dell’invio di un email (possiamo avere quindi un solo tipo di
Workable
), ma tutte e tre hanno una diversa priorità:Nel primo caso vogliamo che l’email arrivi il prima possibile, l’utente é davanti allo schermo che attende quell’email e vogliamo dargli il miglior servizio possibile, inoltre più tardi arriva e più é facile che l’acquisto venga abbandonato.
Nel secondo caso vogliamo che l’email arrivi non troppo dopo che l’acquisto sia stato completato ma senza neanche una particolare fretta, cercando un compromesso tra il dare il miglior servizio possibile all’utente e a non sovraccaricare troppo il nostro sistema.
Nell’ultimo caso invece non abbiamo nessuna fretta, infatti che l’email venga inviata dopo 7 giorni esatti o dopo 7 giorni e 2 minuti cambia molto poco, l’utente non se ne accorgerà ed anche il business (in questa nostra ipotesi) non ne risentirà.
Per attuare questa strategia possiamo innanzitutto suddividere i jobs in diversi gruppi, in questo specifico caso andremo quindi a creare 3 gruppi:
- double-optin-email (or high-priority)
- confirmation-email (or generics)
- follow-up-email (or low-priority)
Una volta fatto ciò, andremo ad istruire i
workers
per prendersi carico solo di una determinata tipologia di gruppo. In questo modo, grazie al numero di workers
presenti su ogni coda (gruppo) avremo velocità di evasione dei jobs
differenti.Ad esempio supponiamo di voler abilitare sette workers, possiamo suddividerli in questa modalità:
- 1 worker che lavora sulla coda
follow-up-email
(orlow-priority
) - 2 worker che lavorano sulla coda
confirmation-email
(orgenerics
) - 4 worker che lavorano sulla coda
double-optin-email
(orhigh-priority
)
Cosi facendo verrà eseguito:
- un solo job facente parte del gruppo
follow-up-email
alla volta (Quindi nel caso in cui ci siano 2 jobs nel gruppolow-priority
schedulati entrambi per lo stesso orario, il secondo verrà eseguito solo al termine del primo). - due job facenti parti del gruppo
confirmation-email
in parallelo - quattro job facenti parti del gruppo
double-optin-email
in parallelo
In linea di massima possiamo affermare che più worker ci sono per una determinata coda (gruppo) e più quella coda verrà smaltita velocemente.
Per limitare il lavoro di un worker ad uno specifico gruppo di jobs dovremo utilizzare l’opzione work-on al lancio del processo worker.
Ad esempio:
$ php vendor/bin/recruiter start:worker --work-on='double-optin-email' --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php
$ php vendor/bin/recruiter start:worker --work-on='double-optin-email' --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php
$ php vendor/bin/recruiter start:worker --work-on='double-optin-email' --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php
$ php vendor/bin/recruiter start:worker --work-on='double-optin-email' --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php
$ php vendor/bin/recruiter start:worker --work-on='confirmation-email' --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php
$ php vendor/bin/recruiter start:worker --work-on='confirmation-email' --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php
$ php vendor/bin/recruiter start:worker --work-on='follow-up-email' --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php