Чи діє Діснеївська швидка шпаргалка та / або корисна теорія черги

У Disney World вони використовують систему під назвою Fastpass для створення другої, коротшої лінії для популярних атракціонів. Ідея полягає в тому, що ви можете зачекати в стандартній лінійці, часто із запіканням довше години, або ви можете отримати FastPass, який дозволяє повернутися протягом визначеного часового блоку (як правило, через пару годин) і лише чекати 10 хвилин або менше. За допомогою FastPass ви можете "чекати" одночасно лише одну їзду.

Я намагаюся розібратися з теорією черг, що стоїть за цією концепцією, але єдине пояснення, яке я знайшов, - це те, що вона створена для того, щоб вивести людей з ладу і робити речі, які принесуть додатковий дохід (шопінг, їжа тощо).

Чому FastPass був реалізований, чи існує реальна проблема ефективності відвідувачів, яку він вирішує? Чи є програмні програми, які застосовують подібну логіку? Чи є програмні програми, які повинні застосовувати подібну логіку?

Частина проблеми, яку я бачу при впровадженні чогось подібного в програмне забезпечення, полягає в тому, що він базується на виборі черги користувачів. До швидших циклів очікування програмного забезпечення, я думаю, що для хорошого застосування цієї теорії потрібно, щоб програма була достатньо розумною, щоб знати, які черги розміщувати людей, виходячи з їх потреб, не вимагаючи вибору кінцевого користувача.

Лінія швидкого проходу, очевидно, не збирається збільшити загальну пропускну спроможність в заданій черзі їзди, але вона допомагає в плануванні ресурсів і призначенні ресурсів, де ресурси і люди.

Як я вже говорив, ви не збираєтеся створювати більше загальної пропускної здатності для зазначеної їзди, але, можливо, в інших місцях їзди будуть недостатньо використані. Якщо ви зараз можете їздити на цих атракціонах, а також на атракціони, які вам доведеться чекати, то ви можете підвищити загальну ефективність роботи парку. Що я маю на увазі під цим, це мінімізувати кількість їзди, що працюють нижче пасажирських можливостей.

Якщо у вас в режимі очікування сидять комп’ютерні ресурси, очікуючи на виконання завдання, яке може зайняти тривалий час, є сенс використати цей ресурс для чогось іншого, чи не так? З цього погляду все просто.

Йдеться про накопичення, а не про ефективність черги.

Fastpass працює, тому що робить окремі елементи в черзі більш ефективними для "споживання" чогось. Це не стільки черга, як процесор, який очікує виконання інструкцій, скільки люди, які чекають в черзі їжі.

Що стосується людей у ​​Діснейленді, це дозволяє їм максимально розважатись .

Подумайте про процесор, який приймає інструкції. Кожна інструкція чекає, щоб її виконали в черзі, щоб виконати своє завдання. Тепер змініть це - уявіть, що кожна інструкція чекає в черзі не для того, щоб виконати інструкцію, а щоб отримати щось від процесора - кожен раз, коли він потрапляє на процесор, він нагороджується золотою зіркою, а його завдання - накопичити стільки з них якомога.

Fastpass - це як дозволяти інструкції піти куди-небудь ще, до іншого процесора, отримати там золоту зірку, перш ніж повернутися до основного процесора, щоб отримати золоту зірку від неї.

Що стосується користувачів Disneyland, вони зацікавлені у розвазі - накопиченні досвіду їзди. Fastpass дозволяє зробити максимізацію, дозволяючи користувачеві знайти іншу їзду з коротшою лінією, щоб вони могли накопичити більше за коротший час.

Я спробував FastPass, і ось як я це бачу:

Скажімо, ви їдете на їзду з очікуваним часом очікування, якщо ви перейдете на FastPass, ви отримаєте призначений проміжок часу, коли вам гарантовано негайний в'їзд. Зазвичай це більше 1 години.

Ми отримали FastPasses для популярних атракціонів, і за цей час, у черзі в 10-15 м черг, що дозволяє нам стояти в черзі та йти на 3 атракціони, перебуваючи у віртуальній черзі FastPass. Вони також дали нам додаткові незлічені FastPasses на дуже непопулярні атракціони, якби ми використали ті, ми отримаємо трохи навантаження на більш популярні атракціони та заповнимо дуже непопулярні.

Ось графічне порівняння часу, який ми витратили проти опції непрохідного пропуску:

Мені це здається справедливою теорією черг, вона дозволяє виконувати ресурси з меншим очікуваним часом очікування, затримуючи один із більшим очікуваним часом очікування ще більше.

FastPass в основному реалізує не блокуючих відвідувачів певну чергу пріоритетів. Вони не блокують, не сплять, вони витрачають гроші. Це працює, тому що Джон використовує його в 11:00, Джо використовує його в 11:15 (або 11:01). Тепер, якби кожен мав швидкий проїзд, регулярна лінія була б набагато швидшою, тоді як більшість відвідувачів витрачали більше грошей на їжу та подарунки. Для Діснея - це бажаний ефект, певною мірою.

Пропуск робить деякі припущення і має деякі обмеження. Це передбачає, що власники швидкого проходу - меншість. Якщо це зміниться, їм доведеться змусити роботу пропускати роботу на декількох атракціонах, або власники швидкого проходу витратять гроші, побачивши дуже мало людей на регулярній лінії .. контрпродуктивна. Оскільки підтримується лише одна їзда, жодне з двох власників швидкого проходу не запитуватиме одну й ту ж їзду одразу.

Тепер, враховуючи, що Джо, можливо, покине парк до початку своєї черги, вам доведеться придумати якийсь «футекс» для відвідувачів, щоб зробити систему ефективною. Якщо Джо пішов, а Джон прийшов рано, Джон міг би покататися. Більше того, Джон би здивувався, чому його швидкий пропуск не сповістив його про те, що він швидше може їздити на nn хвилини. Ось де насправді стає весело, а що, якщо Джо пішов просто, щоб отримати трохи сонцезахисного крему з машини та повернувся? Зрештою, його черга за дві години, якщо тільки 200 людей до нього не покинули парк, поки він блокував (отримуючи сонцезахисний крем), завдання, яке не можна перервати. Тож у цьому випадку ми ставимо Джо в якийсь дисковий сон, або сон, який неможливо перервати чи вбити. Він не отримує сигналів, нічого не опитує, він виходить з парку.

Це така теорія, яка керує практичним програмуванням без блокування. Це настільки ж цікаво, як проблема філософів їдальні , насправді більше.

Що стосується Діснея .. це не помилка, її особливість, люди менш схильні покидати парк, а більш схильні витрачати гроші.

У звичайній черзі ви не можете реально оцінити, наскільки швидко ви їдете. Ви нервуєтесь і часом думаєте про те, щоб просто відмовитися від ідеї.

Завдяки FastPass ви "знаєте", що їзда відбудеться в точно визначений часовий проміжок. Ви "впевнені", коли це станеться, і думаєте про те, щоб кинути рідше. Ви ходите по магазинах і їсте і повертаєтесь, коли потрібно. Ви, ймовірно, повернетесь, оскільки подали заявку на проїзд заздалегідь і відчуєте прихильність. Джоел Спольський описує подібну ідею зобов'язань, яку використовують у чергах Starbucks .

Тож FastPass - це свого роду зручність як для парку, так і для відвідувачів. Відвідувачі більше в захваті, і парк може продати їх більше, поки вони чекають.

Просто приклад хорошої соціальної інженерії.

Я думаю, що ви могли б порівняти це з асинхронною моделлю програмування .

Ви просите систему виконати дію, і ви пізніше повернетесь за результатом.

Велика різниця полягає в тому, що ви або вказуєте, яку подію / зворотний виклик потрібно зателефонувати після завершення, або потрібно ввести очікування в той момент, коли ви готові чекати. Я не бачив механізму, який би сказав вам повернутися пізніше та гарантувати менший час очікування.

Мені це здається чергою пріоритетів .

Під час першого вживання SpeedPass вищий пріоритет. Потім , коли з'являються у general line queueв SpeedPass має більший пріоритет в черзі.

І якщо ми згодні з тим, що це черговість з пріоритетом, то найбільш очевидною реалізацією програмного забезпечення є планування ОС

Змінено із статті Вікі про планування:

Діснейленд планувальник має справу в основному з:

• Використання їзди - щоб максимально зайняти їзду.
  
• Пропускна здатність - кількість людей, які завершили свою їзду за одиницю часу.
  
• Поворот - кількість часу на виконання певної їзди.
  
• Час очікування - кількість часу, яку людина чекала в черзі готових.
  
• Час відповіді - кількість часу, яке минуло від того, коли рядок був у черзі, до появи першої відповіді.
  
• Справедливість - рівний час їзди для кожної людини.
  

Ідея FastPass для мене виглядає як рішення для систем, де мені потрібно виконувати завдання від 1 до N, і грунтуючись на певних знаннях, які я маю про себе (у Діснеї, я можу знати, що мої діти будуть дуже раді їздити на тестовій доріжці, поки чекають на Час прибуття Soarin 'FastPass для приходу) Я міг запланувати себе, щоб зайти в чергу' FastPass 'для завдання N, а також потрапити в стандартну чергу для завдання M. Це діяло б там, де порядок завдання не обов'язково важливий і де час черги було відомо, і я міг оцінити, скільки часу знадобиться для виконання завдання M або N. Не впевнений, що у мене є хороший приклад програмування в реальному світі - значна частина нашого мислення має лінійний характер, і тому наші робочі процеси мають тенденцію бути таким. .

FastPass дозволяє вам чекати в декількох рядках одночасно. Це дозволяє уникнути очікування, але збільшує середній час очікування, оскільки лінії ефективно збільшуються довше.

Але більшість людей не витрачали весь свій час на поїздки. Деякі події, як паради, насправді не мають часу очікування. Використовуючи швидкий пропуск, ви можете перейти до більшості цих позалінійних або коротколінійних подій, не приносячи в жертву стільки атракціонів.

Є два місця, які мені спадають на думку, які мають схожу поведінку в розробці програмного забезпечення для мене. Однак і точної аналогії немає, оскільки вони вимагають обох

Перший - це асинхронне програмування. Як вже згадувалося раніше , існують деякі відмінності між моделлю асинхронізації та моделлю швидкого проходу з точки зору того, як ви чекаєте. Однак деякі інші моделі програмування (наприклад, інтерфейс передачі повідомлень) ) дають вам інші варіанти, які, ймовірно, трохи наближаються до моделі FastPass.

Зокрема, я думав про методи MPI_Gather в MPI - вони використовують модель, напевно, трохи ближче. Кожна функція передається навколо кластеру, і тоді ви можете зателефонувати збирати з кореня, щоб отримати дані, що обробляються в даний час. Мета така ж (утримувати всіх, хто менше чекає [не блокувати користувача] і ходити, витрачати [чи обробляти дані]).

Інше місце, де я можу побачити подібність, є в передових моделях програмування різьблень, таких як новий планувальник у TPL . Однією з головних переваг TPL, що надходить у C # 4, є те, що планувальник дозволить працювати з крадіжкою, що мені здається чіткою реалізацією в програмному забезпеченні спроби динамічно пересуватися навколо ліній - що пов'язано з FastPass. Одна з приємних речей з швидким проїздом - це те, що ти сидиш в черзі менше, їдеш більше і більше рухаєшся. З TPL, ми (сподіваємось) менше блокуємо і чекаємо, оскільки нитка, яка закінчила свою чергу, може вкрасти завдання з інших черг.

Одним із цікавих аспектів FastPass є те, що він впроваджує канал зворотного зв’язку для Діснея. Маючи єдиний рядок, який майже завжди чекає, коли притягнення стане доступним, ви не можете багато чого зробити, крім того, щоб якось виміряти, як довго ця лінія знаходиться у встановлені інтервали часу протягом дня. Використовуючи FastPass Disney збирає дані попиту та трафіку за атракціоном у режимі реального часу та вже оцифровані - він повинен негайно перейти до їх сховища даних для видобутку.

Я схильний погоджуватися, що ті, хто кваліфікує FastPass як систему розподілу ресурсів, більше, ніж систему черги на ресурси. Іншою аналогією було б трактувати кожного клієнта Disney як процес ОС, який є однопоточним, поки клієнт не підбере FastPass. Це робить замовника двопотоковим процесом, який продовжує їздити на велосипеді по парку, як і раніше, і працює інший потік, який чекає своєї черги на визначений ресурс (FastPass притягання). Дозволення декількох FastPasses користувачам (процесам) зробить такі процеси більш багатопотоковими. Синхронізація ниток відбувається, коли клієнт нарешті потрапляє до атракціону FastPass, щоб насолодитися ним.

Єдина аналогія програмного забезпечення, яку я бачу, полягає в тому, що цей метод дозволяє уникнути переповнення буфера черги - якщо багато клієнтів намагаються додати до черги приблизно в той самий час, вона може швидко заповнити цю чергу. Якщо клієнтів пропонують почекати певний проміжок часу, то їм доведеться зберігати місце (порівняно) менше елементів локально перед тим, як додати до черги.

Однак у більшості інших випадків це призводить до менш ефективної пропускної здатності, оскільки це може призвести до того, що черга стане голодною, якщо час очікування буде погано обраний.

Спробуйте написати тестову програму, яка використовує черги як з "FastPass", так і без них, під різними показниками та порівнюючи результати - і повідомте нас, якщо ви знайдете щось цікаве! :)

Не знаєте, як це було б застосовано в програмному забезпеченні. Але система, безумовно, має свої переваги для відвідувачів: ви можете проїхати Fastpass за одну їзду, а тим часом перейти до іншої їзди, лінія якої не така довга (або, як ви кажете, ходити по магазинах, їсти тощо). Це було цілком рятівним життям, коли я та моя родина були там (правда, це був міжсезоння).

Враховуючи, що це експлуатується , вам доведеться довіряти користувачам черги ;-)

З мого класу ланцюгів поставок, аспект черги, який прийшов до мене негайно, полягає в тому, що це скорочує ваш сприйнятий час очікування, тому люди зовсім не проти чекати. Я не думаю, що це скорочує основні лінії, але це полегшує чиїсь тривоги щодо очікування на регулярній лінії, оскільки вони знають, що як тільки вони вийдуть з їзди, вони можуть повернутися прямо вдруге (якщо їх швидкий проїзд час закінчився, все одно).

Я знаю, що це сприймає, що я можу їздити набагато більше їзди з швидким проїздом, хоча я не знаю, чи це насправді так, чи це просто розумне переоформлення мого часу очікування.

Єдине пояснення, яке я знайшов, - це те, що воно розроблене для того, щоб вивести людей з ладу і робити речі, які принесуть додатковий дохід (покупки, їжа тощо).

Я думаю, що ви потрапили на головну точку там, але ви робите це звуком більше корпоративно-злим, ніж, можливо, це заслуговує. Я б, звичайно, швидше "практично в черзі" під час покупок і їжі, ніж фізично черга в рядку.

Теоретично FastPass може спробувати запланувати більше людей у ​​періоди, коли природний попит був нижчим; ось що б ви зробили, щоб отримати більше пропускної здатності з реальної запланованої черги. Але на практиці я підозрюю, що їзди працюють майже на потужність більшу частину дня, тож продуктивність від цього мало отримати.

Йдеться про планування ресурсів для популярних атракціонів, а також про спосіб отримання додаткового доходу, продаючи товари. Якщо ви чекаєте в черзі, це означає, що вам не надається можливість витратити більше грошей.

В інтересах Діснея задовольняти своїх клієнтів. Хоча мерчандайзинг, безумовно, є значним доходом, отримання повторних клієнтів у багато разів цінніше.

Якщо я заплачу 150 доларів за 1-денний квиток на парк-бункер і я лише пройду 10 поїздок, тому що лінії такі довгі, я б заперечував, чи справді ці атракціони коштують 15 доларів за штуку. Якщо, однак, є спосіб, щоб я поїхав на 30 атракціонів, тоді у мене буде кращий досвід, менша ймовірність поставити під сумнів цінність цього досвіду і з більшою ймовірністю повернуться і дадуть Діснейленду ще 150 доларів + їжа + товар.

Перед FastPass єдиним диференціатором між моїм 10 їздом та 30 їздами було те, наскільки переповнений парк. Це поширена проблема, яку інші бажані пам'ятки намагалися вирішити іншими способами. Наприклад, гірськолижний курорт Northstar в Тахо обмежить кількість ліфтових квитків, які вони продають за певний день (або принаймні раніше). Це також вирішує проблему, але таким чином, що більш негативно позначається на доходах.

У програмному забезпеченні подібна парадигма буде завантажувати веб-сторінку. У стародавні часи цей процес був єдиним потоком: отримайте весь контент, візуалізуйте весь вміст і покажіть сторінку. Зі збільшенням трафіку та даних (конкретно, з внесенням зображень) ця модель зіткнулася з тією ж проблемою, що і в Діснейленді. Якби зображень на сторінці було багато, і завантаження зайняло тривалий час, я б не чекав вмісту і, можливо, не турбував би колись повернутися на цей сайт.

Зараз веб-сторінки завантажуються по-різному. Вміст завантажується, надається та відображається спочатку, тоді як інша нитка завантажується, візуалізується та відображає зображення. Це значно покращує користувацький досвід, і, якщо є бажаний контент, я продовжуватиму повертатися на сайт, і це може перетворити мої неодноразові перегляди сторінок на $$$.

Це певною мірою нагадує ОС у режимі реального часу.

Деякі процеси мають швидкий прохід і позначаються як в режимі реального часу.

Вони мають гарантію, що отримають ресурс протягом певного періоду часу. Вони не можуть стрибати з черги, але вони можуть просуватися! Хоча вони не користуються їздою, інші гості в режимі реального часу можуть користуватися нею.

-Алекс

Це чудові речі. Дісней по суті робить дві черги з лінійно нижчими тарифами обслуговування залежно від кількості розподілених FASTpass.

Коротку чергу FASTpass можна моделювати як чергу, яка завжди знаходиться в рівновазі для короткого очікування. Тримання черги короткою мінімізує зворотний зв'язок між двома чергами - що добре для стохастичного моделювання. Інша черга - типова черга, з повільнішою швидкістю обслуговування.

Звичайно, якщо квота FASTpass коли-небудь отримала занадто велику кількість, настане зворотний зв'язок між двома чергами, зробивши систему Хаотичною та мінімізувавши ефект моделей черги для опису результатів.

Інша стратегія полягає в тому, щоб мінімізувати очікування користувачів, було б суворо розкладати поїздки за домовленістю; в цьому випадку це чиста партійна черга, і її легко оптимізувати. Я не думаю, що це би спрацювало в США. :-)

Ви не їдете на більше їзди. Лінії для непопулярних ліній зараз довші, тому що все більше людей вбивають на них час, чекаючи, поки їхній популярний проїзд пройде до дозрівання. Ємність - це ємність.

"Наразі Twitter справді зайнятий. Поверніться між 15:00 та 15:15, і ми гарантуємо вам отримати твіт протягом 5 секунд або менше".