Disney FastPass è valido e / o teoria delle code utile

A Disney World, usano un sistema chiamato Fastpass per creare una seconda linea più corta per le corse più popolari. L'idea è che puoi aspettare nella linea standard, spesso con un'attesa più lunga di un'ora, oppure puoi ottenere un FastPass che ti consente di tornare durante un determinato intervallo di tempo (di solito un paio d'ore dopo) e attendere solo 10 minuti o meno. Puoi solo "aspettare" una corsa alla volta con un FastPass.

Ho cercato di capire la teoria delle code alla base di questo concetto, ma l'unica spiegazione che ho trovato è che è progettato per far uscire le persone dalle linee e fare cose che porteranno entrate aggiuntive (shopping, cibo, ecc.).

È per questo che FastPass è stato implementato o c'è un vero problema di efficienza dei visitatori che sta risolvendo? Esistono applicazioni software che hanno applicato una logica simile? Esistono applicazioni software che dovrebbero applicare una logica simile?

Parte del problema che vedo nell'implementare qualcosa di simile nel software è che si basa sulla scelta della coda da parte degli utenti. Fare per i cicli di attesa più veloci nel software, penso che una buona applicazione di questa teoria richiederebbe che l'applicazione sia abbastanza intelligente da sapere in quali code collocare le persone in base alle loro esigenze senza richiedere la scelta dell'utente finale.

Ovviamente la linea di passaggio rapido non aumenterà la produttività totale in una determinata coda, ma aiuta nella pianificazione delle risorse e nell'assegnazione delle risorse in cui le persone e le giostre sono le risorse.

Come ho detto, non avrai intenzione di creare un throughput più totale per detta corsa, ma potrebbero esserci corse non utilizzate altrove. Se ora sei in grado di cavalcare queste giostre e le giostre su cui devi aspettare, puoi aumentare l'efficienza complessiva del parco. Quello che intendo con questo è minimizzare la quantità di corse che corrono al di sotto della capacità dei passeggeri.

Se le risorse del computer sono inattive, in attesa di eseguire un'attività che potrebbe richiedere molto tempo, ha senso utilizzare questa risorsa per qualcos'altro nel frattempo, giusto? È semplice da quella prospettiva.

Si tratta di accumulo, non di efficienza in coda.

Fastpass funziona perché rende i singoli elementi nella coda più efficienti nel "consumare" qualcosa. Non è tanto una coda come un processore in attesa di istruzioni da eseguire quanto lo sono le persone in fila per il cibo.

Nel caso delle persone a Disneyland, consente loro di massimizzare il loro divertimento .

Pensa a un processore che accetta le istruzioni. Ogni istruzione è in attesa di essere eseguita nella coda, per eseguire il suo compito. Ora modificalo - immagina che ogni istruzione sia in coda non per eseguire un'istruzione, ma per ottenere qualcosa dal processore - ogni volta che colpisce un processore viene premiata con una stella d'oro e il suo compito è accumulare altrettante di queste il più possibile.

Fastpass è come consentire alle istruzioni di andare altrove, su un altro processore, per ottenere lì una stella d'oro, prima di tornare al processore principale per ottenere da essa la stella d'oro.

Nel caso degli utenti di Disneyland, sono interessati a divertirsi - accumulando esperienze di guida. Il Fastpass consente una massimizzazione consentendo all'utente di trovare una corsa diversa con una linea più corta, in modo che possano accumularsi di più in un tempo più breve.

Ho provato FastPass, ed è così che lo vedo:

Supponiamo che tu vada a fare un giro con 1 ora di attesa prevista, se vai su FastPass, riceverai un periodo di tempo assegnato in cui ti viene garantito l'ingresso immediato. Di solito è dopo più di 1 ora.

Abbiamo ottenuto FastPasses per le corse più popolari e durante quel periodo, abbiamo fatto la coda in 10-15m di coda, permettendoci di fare la fila e andare a 3 corse mentre eravamo nella coda virtuale FastPass. Ci hanno anche dato FastPass extra non conteggiati ad alcune corse molto impopolari, se avessimo usato quelle avremmo avuto un po 'di carico dalle corse più popolari e riempito quelle molto impopolari.

Ecco un grafico che confronta il tempo che abbiamo trascorso rispetto all'opzione non fastpass:

Mi sembra una teoria di accodamento valida, che consente di eseguire risorse con tempi di attesa meno previsti ritardandone una con un tempo di attesa atteso superiore ancora di più.

FastPass implementa sostanzialmente i visitatori non bloccanti con una sorta di coda prioritaria. Non bloccano, non dormono, spendono soldi. Funziona perché john lo usa alle 11:00, joe lo usa alle 11:15 (o alle 11:01). Ora, se tutti avessero un passaggio veloce, la linea regolare sarebbe molto più veloce mentre la maggior parte dei visitatori spende più soldi per cibo e regali. Per Disney, questo è l'effetto desiderato, fino a un certo punto.

Il pass fa alcune ipotesi e presenta alcune limitazioni. Presuppone che i possessori di fastpass siano la minoranza ... se ciò fosse cambiato, dovrebbero far funzionare il pass su più corse, oppure i detentori di fastpass spenderebbero denaro vedendo pochissime persone nella linea normale ... controproducenti. Poiché è supportato un solo passaggio, non è necessario che due possessori di fastpass richiedano lo stesso passaggio contemporaneamente.

Ora, considerando che Joe potrebbe lasciare il parco prima di fare il suo turno, dovresti trovare una sorta di "futex" dei visitatori per rendere efficiente il sistema. Se Joe se ne andasse e John arrivasse presto, John poteva cavalcare. Inoltre, John si chiederà perché il suo passaggio veloce non gli abbia comunicato che avrebbe potuto guidare nn minuti prima. È lì che ci si diverte davvero, e se Joe se ne andasse solo per prendere una protezione solare dall'auto e tornare? Dopotutto, il suo turno è tra due ore, a meno che altre 200 persone prima di lui abbiano lasciato il parco mentre stava bloccando (mentre si prendeva la protezione solare), un compito che non può essere interrotto. Quindi, in quel caso, mettiamo Joe in una sorta di sospensione del disco, o sospensione che non può essere interrotta o uccisa. Non riceve segnali, non sta sondando nulla, è fuori dal parco.

Questo è il tipo di teoria che guida la pratica programmazione senza blocchi. È interessante quanto il problema dei filosofi culinari , anzi di più.

Per quanto riguarda la Disney ... questo non è un bug, è una caratteristica, le persone sono meno inclini a lasciare il parco mentre sono più inclini a spendere soldi.

In una coda normale non puoi davvero stimare quanto velocemente ottieni il tuo giro. Sei nervoso e a volte pensi di abbandonare l'idea.

Con FastPass "sai" che la corsa avverrà in un periodo di tempo definito con precisione. Sei "sicuro" di quando succede e pensi di smettere meno spesso. Fai shopping e mangi e ritorni quando necessario. È probabile che tu ritorni poiché hai richiesto la corsa in anticipo e senti l'impegno. Joel Spolsky descrive un'idea di impegno simile utilizzata nelle code di Starbucks .

Quindi FastPass è una sorta di comodità sia per il parco che per i visitatori. I visitatori sono più felici e il parco può venderli di più mentre aspettano.

Solo un esempio di buona ingegneria sociale.

Penso che potresti paragonarlo a un modello di programmazione asincrono .

Chiedete al sistema di eseguire un'azione e tornerete più tardi per il risultato.

La grande differenza è che specifichi quale evento / callback chiamare quando hai finito o devi inserire l'attesa nel momento in cui sei pronto ad aspettare. Non ho visto un meccanismo che ti direbbe di tornare in un secondo momento e di garantire tempi di attesa più bassi.

Per me questa sembra una coda prioritaria .

Quando si prende per la prima volta uno SpeedPass si ottiene una priorità più alta. Quindi quando si stacca general line queuelo SpeedPass ha maggiore priorità nella coda.

E se siamo d'accordo che questa è una coda prioritaria, l'implementazione del software più ovvia è pianificazione del sistema operativo

Modificato dall'articolo wiki di pianificazione:

Lo schedulatore Disney Land si occupa principalmente di:

• Utilizzo del giro - per mantenere il viaggio il più occupato possibile.
  
• Produttività: numero di persone che completano la corsa per unità di tempo.
  
• Turnaround - quantità di tempo per eseguire una corsa particolare.
  
• Tempo di attesa - quantità di tempo in cui una persona è stata in attesa nella coda pronta.
  
• Tempo di risposta: tempo impiegato dal momento in cui la linea è stata messa in coda fino alla produzione della prima risposta.
  
• Equità: pari tempo di percorrenza per ogni persona.
  

L'idea di FastPass per me sembra una soluzione per i sistemi in cui ho bisogno di eseguire le attività da 1 a N e sulla base di alcune conoscenze che ho di me stesso (alla Disney, potrei sapere che i miei figli sarebbero molto felici in sella a Test Track mentre aspettavano il Soarin 'Fuso orario FastPass per arrivare) Potrei programmare me stesso per andare nella coda' FastPass 'per l'attività N e anche entrare nella coda standard per l'attività M. Questo funzionerebbe dove l'ordine delle attività non è necessariamente importante e dove il tempo della coda era noto e potrei stimare quanto tempo ci vorrebbe per svolgere il compito M o N. Non sono sicuro di avere un buon esempio di programmazione nel mondo reale - gran parte del nostro pensiero è di natura lineare e quindi i nostri flussi di lavoro tendono ad essere in quel modo .

FastPass ti consente di attendere su più righe contemporaneamente. Ti consente di evitare l'attesa, ma aumenta il tempo medio di attesa perché le linee diventano effettivamente più lunghe.

Ma la maggior parte delle persone non passa tutto il tempo a cavalcare. Alcuni eventi, come le sfilate, non hanno davvero un tempo di attesa. Usando un passaggio veloce puoi andare a più di questi eventi senza linea o su linea corta senza sacrificare il numero di corse su linea lunga.

Ci sono due posti che mi vengono in mente che hanno un comportamento simile nello sviluppo del software per me. Tuttavia, nessuna delle due è un'analogia esatta, poiché entrambe richiedono

Il primo è la programmazione asincrona. Come accennato in precedenza , ci sono alcune differenze tra il modello asincrono e il modello fastpass, in termini di modalità di attesa. Tuttavia, alcuni altri modelli di programmazione (come Message Passing Interface ) offrono alcune altre opzioni, che probabilmente si avvicinano un po 'al modello FastPass.

In particolare, stavo pensando ai metodi MPI_Gather in MPI: usano un modello probabilmente un po 'più vicino. Ogni funzione viene distribuita intorno al cluster e quindi è possibile chiamare raccogliere dalla radice per ottenere i dati attualmente elaborati. L'obiettivo è lo stesso (far aspettare meno tutti [non bloccare l'utente] e camminare, spendere [o elaborare i dati]).

L'altro posto in cui posso vedere una somiglianza è nei modelli avanzati di programmazione threaded, come il nuovo scheduler nel TPL . Uno dei principali vantaggi del TPL che arriva in C # 4 è che lo scheduler consentirà il furto di lavoro, che a me sembra una chiara implementazione nel software di provare a spostarsi dinamicamente sulle linee - che si ricollega a FastPass. Una delle cose carine di fastpass è che ti siedi in fila meno, pedali di più e ti muovi di più. Con TPL, c'è (si spera) meno blocchi e attese, poiché un thread che ha terminato la sua coda può rubare attività da altre code.

Un aspetto interessante di FastPass è che introduce un canale di feedback per Disney. Avendo una sola linea che quasi sempre attende che l'attrazione diventi disponibile, non c'è molto che puoi fare tranne che in qualche modo misurare la durata della linea a intervalli di tempo fissi durante il giorno. Utilizzando FastPass Disney raccoglie i dati sulla domanda e sul traffico per attrazione in tempo reale e già digitalizzati: dovrebbe andare immediatamente al loro data warehouse per il mining.

Tendo a concordare sul fatto che coloro che qualificano FastPass come sistema di allocazione delle risorse più di un sistema di accodamento delle risorse. Un'altra analogia sarebbe quella di trattare ogni cliente Disney come un processo OS che è un thread singolo fino a quando un cliente prende un FastPass. Questo rende il cliente un processo a 2 thread che continua a pedalare nel parco come prima e sta eseguendo un altro thread che attende il suo turno per la risorsa designata (attrazione FastPass). Consentire più FastPasses agli utenti (processi) renderà tali processi più multithread. La sincronizzazione del thread ha luogo quando il cliente arriva finalmente all'attrazione di FastPass per goderne.

L'unica analogia software che posso vedere è che questo metodo evita il sovraccarico del buffer di coda - se molti client provano tutti ad aggiungere una coda all'incirca nello stesso momento in cui potrebbero riempire rapidamente quella coda. Se ai client viene chiesto di attendere un determinato periodo di tempo, devono prima eseguire il buffer dei loro (relativamente) pochi elementi a livello locale prima di aggiungerli alla coda.

Nella maggior parte degli altri casi, tuttavia, ciò porta a un throughput meno efficiente in quanto potrebbe causare la perdita di fame della coda se i tempi di attesa sono scelti in modo inadeguato.

Prova a scrivere un'applicazione di prova che utilizza l'accodamento con e senza "FastPass" sotto varie metriche e confrontando i risultati - e facci sapere se trovi qualcosa di interessante! :)

Non so come verrebbe applicato nel software. Ma il sistema ha sicuramente i suoi vantaggi per i visitatori: puoi avere un Fastpass per un giro e nel frattempo andare a un altro giro la cui linea non è lunga (o, come dici tu, fare shopping, mangiare, ecc.). Fu un vero toccasana quando io e la mia famiglia eravamo lì (anche se, ammettiamolo, era la bassa stagione).

Dato che viene sfruttato , dovresti fidarti degli utenti della coda ;-)

Dalla mia classe di filiera, l'aspetto della fila che mi è venuto subito è che riduce i tempi di attesa percepiti, quindi alla gente non dispiace aspettare affatto. Non penso che accorcia le linee principali, ma allevia l'ansia di qualcuno di aspettare nella linea normale, poiché sanno che non appena scendono dal giro, possono tornare subito una seconda volta (se il loro fastpass il tempo è scaduto, comunque).

So che percepisco che posso guidare molte più corse con il fastpass, anche se non so se sia effettivamente il caso o se sia solo una rielaborazione intelligente del mio tempo di attesa.

l'unica spiegazione che ho trovato è che è progettato per far uscire le persone dalle linee e fare cose che porteranno entrate aggiuntive (shopping, cibo, ecc.).

Penso che tu abbia centrato il punto principale, ma lo fai sembrare più malvagio di quanto meriti. Preferirei piuttosto "fare la fila virtualmente" mentre faccio shopping e mangiare piuttosto che fare la fila fisicamente in fila.

Teoricamente, FastPass potrebbe provare a programmare più persone nei momenti in cui la domanda naturale era inferiore; questo è quello che faresti per ottenere più throughput da una vera coda pianificata. Ma in pratica, sospetto che le corse stiano funzionando praticamente a pieno regime per gran parte della giornata, quindi c'è poca produttività da ottenere da questo.

Si tratta della pianificazione delle risorse per corse popolari e di un modo per generare entrate aggiuntive vendendo merce. Se stai aspettando in fila, significa che non ti è stata data l'opportunità di spendere più soldi.

È nel migliore interesse della Disney soddisfare i propri clienti. Mentre il merchandising rappresenta sicuramente entrate significative, ottenere clienti abituali è molte volte più prezioso.

Se pago $ 150 per un biglietto park-hopper di 1 giorno e riesco a fare solo 10 corse perché le linee sono così lunghe, mi chiederei se quelle corse valgono davvero $ 15 dollari al pezzo. Se, tuttavia, c'è un modo per me di andare su 30 corse, allora avrò un'esperienza migliore, avrò meno probabilità di mettere in discussione il valore di quell'esperienza ed avere maggiori probabilità di tornare e dare a Disneyland un altro $ 150 + cibo + merce.

Prima di FastPass, l'unico elemento di differenziazione tra le mie 10 corse e 30 corse era quanto fosse affollato il parco. Questo è un problema comune che altre attrazioni desiderabili hanno tentato di affrontare in altri modi. Ad esempio, la stazione sciistica Northstar di Tahoe limiterà il numero di biglietti per gli impianti di risalita che vendono in un determinato giorno (o almeno un tempo). Questo risolve anche il problema, ma in un modo che incide in modo più negativo sulle entrate.

Nel software, un paradigma simile sarebbe il caricamento di una pagina Web. Nell'antichità questo processo era a thread singolo: ottieni tutto il contenuto, visualizza tutto il contenuto e visualizza la pagina. Con l'aumentare del traffico e dei dati (in particolare l'incorporazione delle immagini) questo modello ha dovuto affrontare lo stesso problema di Disneyland. Se ci fossero molte immagini sulla pagina e il caricamento richiedesse molto tempo, non aspetterei il contenuto e non potrei preoccuparmi di tornare su quel sito.

Ora le pagine web vengono caricate in modo diverso. Il contenuto viene caricato, reso e visualizzato per primo mentre un altro thread carica, esegue il rendering e visualizza le immagini. Ciò migliora notevolmente l'esperienza dell'utente e, a condizione che ci siano contenuti desiderabili, continuerò a tornare al sito e può trasformare le mie visualizzazioni di pagina ripetute in $$$.

Questo in qualche modo ricorda un sistema operativo in tempo reale.

Alcuni processi hanno un passaggio rapido e sono contrassegnati come in tempo reale.

Hanno la garanzia che otterranno la risorsa entro un certo periodo di tempo. Non riescono a saltare la coda, ma possono spingere dentro! Mentre non usano la corsa, altri ospiti non in tempo reale possono usarla.

-Alex

Questa è roba fantastica. Disney sta essenzialmente facendo due code, con tariffe di servizio linearmente più basse a seconda del numero di FASTpass distribuito.

La breve coda FASTpass può essere modellata come una coda che è sempre in equilibrio per una breve attesa. Mantenere la coda corta riduce al minimo il feedback tra le due code, il che è utile per la modellazione stocastica. L'altra coda è una coda tipica, con una velocità di servizio più lenta.

Ovviamente, se la quota FASTpass fosse mai troppo elevata, ne conseguirebbe uno svantaggio tra le due code, rendendo caotico il sistema e minimizzando l'effetto dei modelli di accodamento per descrivere i risultati.

Un'altra strategia è quella di ridurre al minimo le attese degli utenti: programmare rigorosamente le corse su appuntamento, nel qual caso si tratta di una coda batch pura e facile da ottimizzare. Non penso che funzionerebbe negli Stati Uniti. :-)

Non sali su altre giostre. Le linee per le linee impopolari sono più lunghe ora, perché più persone stanno ammazzando il tempo su di loro mentre aspettano che i loro passaggi su strada popolare maturino. La capacità è capacità.

"Twitter è attualmente molto impegnato. Torna tra le 15:00 e le 15:15 e ti garantiamo di ricevere i tuoi tweet in 5 secondi o meno."