Является ли Disney FastPass действительной и / или полезной теорией очередей

В Disney World они используют систему Fastpass, чтобы создать вторую, более короткую линию для популярных поездок. Идея состоит в том, что вы можете ждать в стандартной строке, часто с ожиданием более часа, или вы можете получить FastPass, который позволяет вам вернуться в течение определенного временного блока (обычно через пару часов) и ждать только 10 минут или меньше. Вы можете «ждать» только одну поездку с FastPass.

Я пытался выяснить теорию очереди, стоящую за этой концепцией, но единственное объяснение, которое я нашел, состоит в том, что он предназначен для того, чтобы вывести людей из строя и делать то, что принесет дополнительный доход (покупки, еда и т. Д.).

Вот почему был внедрен FastPass, или есть реальная проблема эффективности посетителей, которую он решает? Существуют ли программные приложения, которые применили подобную логику? Существуют ли программные приложения, которые должны применять аналогичную логику?

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

Линия быстрого прохода, очевидно, не собирается увеличивать общую пропускную способность в данной очереди на поездку, но она помогает в планировании ресурсов и назначении ресурсов, где ресурсы и люди едут.

Как я уже сказал, вы не собираетесь создавать больше общей пропускной способности для указанной поездки, но в других местах может быть недостаточно загруженных поездок. Если вы теперь можете ездить на этих аттракционах, а также на аттракционах, на которых вам приходится ждать, вы можете повысить общую эффективность парка. Под этим я подразумеваю минимизацию количества поездок, которые выполняются ниже пассажировместимости.

Если ваши компьютерные ресурсы простаивают, ожидая выполнения задачи, которая может занять много времени, имеет смысл использовать этот ресурс для чего-то еще, не так ли? Это просто с этой точки зрения.

Речь идет о накоплении, а не об эффективности очереди.

Fastpass работает, потому что он делает отдельные элементы в очереди более эффективными в «потреблении» чего-либо. Это не столько очередь, сколько процессор, ожидающий выполнения инструкций, сколько люди, стоящие в очереди за едой.

В случае людей в Диснейленде, это позволяет им максимально развлечься .

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

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

В случае пользователей в Диснейленде, они заинтересованы в том, чтобы получать удовольствие от поездки. Fastpass позволяет максимизировать, позволяя пользователю найти другую поездку с более короткой линией, чтобы они могли накапливать больше за более короткое время.

Я пробовал FastPass, и вот как я это вижу:

Допустим, вы отправляетесь в поездку с ожидаемым временем ожидания 1 ч. Если вы перейдете на FastPass, вы получите назначенный период времени, когда вам гарантирован немедленный вход. Обычно это более чем через 1 час.

Мы получили FastPasses для популярных поездок, и за это время выстроились в очередь в 10-15 м очередях, что позволило нам стоять в очереди и идти на 3 поездки, находясь в виртуальной очереди FastPass. Они также дали нам дополнительные несчетные FastPpass для некоторых очень непопулярных поездок, если бы мы использовали их, мы бы получили некоторую нагрузку от более популярных поездок и заполнили бы очень непопулярные.

Вот график, сравнивающий время, которое мы потратили, с опцией non-fastpass:

Мне кажется, что это правильная теория очередей, она позволяет выполнять ресурсы с меньшим ожидаемым временем ожидания, а задерживать еще более ожидаемое время ожидания.

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

Пропуск делает некоторые предположения и имеет некоторые ограничения. Предполагается, что держатели fastpass составляют меньшинство ... если бы это изменилось, им пришлось бы заставить проход работать на нескольких поездках, или держатели fastpass потратили бы деньги, увидев очень мало людей на обычной линии ... контрпродуктивно. Поскольку поддерживается только одна поездка, ни один из владельцев Fastpass не будет запрашивать одну и ту же поездку одновременно.

Теперь, учитывая, что Джо может покинуть парк до того, как он пойдет на свою очередь, вам придется придумать какой-нибудь «futex» посетителя, чтобы сделать систему эффективной. Если Джо уйдет и Джон приедет рано, Джон сможет покататься. Более того, Джон удивлялся, почему его быстрый пас не уведомил его, что он может ехать на н минут раньше. Вот где это действительно весело, что, если Джо ушел, чтобы взять солнцезащитный крем из машины, и вернулся? В конце концов, его очередь находится в двух часах, если только 200 человек до него не покинули парк, когда он блокировал (получая солнцезащитный крем), задачу, которую нельзя прервать. Таким образом, в этом случае мы помещаем Джо в какой-то режим сна диска, или сна, который не может быть прерван или убит. Он не получает никаких сигналов, он ничего не опрашивает, он вне парка.

Это теория, которая движет практическим программированием без блокировок. Это так же интересно, как проблема столовых философов , на самом деле больше.

Что касается Диснея ... это не ошибка, это особенность, люди менее склонны покидать парк, но более склонны тратить деньги.

В обычной очереди вы не можете оценить, насколько быстро вы доберетесь. Вы нервничаете и иногда думаете просто отказаться от идеи.

С FastPass вы «знаете», что поездка произойдет в точно определенный период времени. Вы «уверены» в том, когда это произойдет, и думаете о том, чтобы бросить курить реже. Вы ходите по магазинам и едите и возвращаетесь, когда это необходимо. Вы, скорее всего, вернетесь, так как подали заявку на поездку заранее и почувствуете приверженность. Джоэл Спольски описывает похожую идею приверженности, используемую в очередях Starbucks .

Так что FastPass - это своего рода удобство как для парка, так и для посетителей. Посетители более рады, и парк может продавать их больше, пока они ждут.

Просто пример хорошей социальной инженерии.

Я думаю, вы могли бы сравнить это с моделью асинхронного программирования .

Вы просите систему выполнить действие, и вы вернетесь позже для результата.

Большая разница в том, что вы либо указываете, какое событие / обратный вызов вызывать, когда закончите, либо должны вводить ожидание в то время, когда вы готовы ждать. Я не видел механизма, который сказал бы вам вернуться позже и гарантированно сократить время ожидания.

Мне это кажется приоритетной очередью .

При первом получении SpeedPass достигается более высокий приоритет. Затем , когда появляются у general line queueв SpeedPass имеет больший приоритет в очереди.

И если мы согласны с тем, что это приоритетная очередь, то наиболее очевидной программной реализацией является планирование ОС

Изменено в статье по расписанию:

Планировщик Дисней Лэнд занимается главным образом:

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

Идея FastPass для меня выглядит как решение для систем, в которых мне нужно выполнять задачи с 1 по N, и основываясь на моих знаниях о себе (в Disney, я мог бы знать, что мои дети будут очень счастливы ехать на тестовой дорожке в ожидании Нарастает время ожидания FastPass) Я мог бы запланировать себя, чтобы войти в очередь «FastPass» для задачи N, а также попасть в стандартную очередь для задачи M. Это сработало бы, когда порядок задач не обязательно важен, и где время очереди был известен, и я мог бы оценить, сколько времени потребуется для выполнения задачи M или N. Хотя я не уверен, что у меня есть хороший пример программирования на практике - большая часть нашего мышления носит линейный характер, и поэтому наши рабочие процессы имеют тенденцию быть такими ,

FastPass позволяет вам ждать в несколько строк одновременно. Это позволяет избежать ожидания, но увеличивает среднее время ожидания, потому что линии эффективно удлиняются.

Но большинство людей не проводят все свое время в поездках. У некоторых событий, таких как парады, нет времени ожидания. Используя быстрый проход, вы можете перейти к большему количеству событий без линий или коротких линий, не жертвуя при этом как можно большим количеством поездок на длинные очереди.

Есть два места, которые приходят мне на ум, и у меня похожее поведение при разработке программного обеспечения. Тем не менее, ни одна из них не является точной аналогией, так как они оба требуют

Первый - это асинхронное программирование. Как упоминалось ранее , между асинхронной моделью и моделью fastpass есть некоторые различия в том, как вы ожидаете. Тем не менее, некоторые другие модели программирования (например, интерфейс передачи сообщений ) предоставляют некоторые другие опции, которые, вероятно, немного ближе к модели FastPass.

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

Другое место, где я вижу сходство, в продвинутых моделях многопоточного программирования, таких как новый планировщик в TPL . Одно из главных преимуществ TPL, появившегося в C # 4, заключается в том, что планировщик позволяет выполнять кражу работы, что мне кажется четкой реализацией в программном обеспечении попыток динамического перемещения по линиям - что связано с FastPass. Одна из приятных особенностей fastpass заключается в том, что вы меньше сидите в очереди, больше ездите и больше двигаетесь. С TPL (надеюсь) меньше блокируется и ждет, так как поток, который закончил свою очередь, может украсть задачи из других очередей.

Одним из интересных аспектов FastPass является то, что он представляет канал обратной связи для Disney. Имея единственную линию, которая почти всегда ждет, пока притяжение станет доступным, вы ничего не сможете сделать, кроме как каким-то образом измерить длину линии с фиксированными временными интервалами в течение дня. Используя FastPass, Disney собирает данные о спросе и трафике на аттракцион в режиме реального времени и уже оцифровывается - он должен немедленно перейти в хранилище данных для майнинга.

Я склонен согласиться с тем, что те, кто квалифицирует FastPass как систему распределения ресурсов больше, чем систему очередей ресурсов. Другая аналогия - рассматривать каждого клиента Disney как процесс ОС, который является однопоточным до тех пор, пока клиент не поднимет FastPass. Это делает клиента двухпоточным процессом, который продолжает цикл по всему парку, как и раньше, и запускает другой поток, ожидающий своей очереди для назначенного ресурса (привлечение FastPass). Разрешение нескольких FastPpass для пользователей (процессов) сделает такие процессы более многопоточными. Синхронизация потоков происходит, когда покупатель наконец получает удовольствие от FastPass.

Единственная аналогия с программным обеспечением, которую я вижу, состоит в том, что этот метод позволяет избежать переполнения буфера очереди - если многие клиенты пытаются добавить в очередь примерно в одно и то же время, это может быстро заполнить эту очередь. Если клиентов просят подождать определенное время, они должны локально буферизовать (относительно) меньшее количество элементов перед добавлением в очередь.

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

Попробуйте написать тестовое приложение, которое использует очереди как с «FastPass», так и без него под различными показателями и сравнивает результаты - и дайте нам знать, если найдете что-нибудь интересное! :)

Не знаю, как это будет применяться в программном обеспечении. Но система определенно имеет свои преимущества для посетителей: вы можете иметь Fastpass на одну поездку, а между тем перейти на другую поездку, чья очередь не такая длинная (или, как вы говорите, ходить по магазинам, есть и т. Д.). Это был настоящий спасатель, когда я и моя семья были там (хотя по общему признанию, это было межсезонье).

Учитывая, что это эксплуатируется , вам придется доверять пользователям очереди ;-)

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

Я знаю, что мне кажется, что я могу ездить намного быстрее с помощью скоростного перехода, хотя я не знаю, так ли это на самом деле, или это просто умное перефразирование моего времени ожидания.

единственное объяснение, которое я нашел, состоит в том, что он предназначен для того, чтобы вывести людей из строя и делать то, что принесет дополнительный доход (покупки, еда и т. д.).

Я думаю, что вы достигли главной цели, но вы делаете это звучащим скорее корпоративно-злым, чем, возможно, того заслуживает. Я, конечно, предпочел бы «виртуально стоять в очереди», делая покупки и есть, чем физически стоять в очереди.

Теоретически, FastPass может попытаться запланировать большее количество людей в периоды, когда естественный спрос был ниже; это то, что вы бы сделали, чтобы получить большую пропускную способность из реальной запланированной очереди. Но на практике я подозреваю, что аттракционы работают в полную силу большую часть дня, поэтому от этого мало что можно получить.

Речь идет о планировании ресурсов для популярных поездок, а также о способе получения дополнительного дохода за счет продажи товаров. Если вы ждете в очереди, это означает, что вам не предоставляется возможность тратить больше денег.

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

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

До FastPass единственным отличием между моими 10 поездками и 30 поездками было то, насколько людным был парк. Это общая проблема, которую другие желательные достопримечательности пытались решить другими способами. Например, горнолыжный курорт Northstar в Тахо будет ограничивать количество билетов на подъемники, которые они продают в данный день (или, по крайней мере, раньше). Это также решает проблему, но таким образом, что более негативно влияет на доход.

В программном обеспечении подобная парадигма будет загружать веб-страницу. В древние времена этот процесс был однопоточным: получать весь контент, отображать весь контент и отображать страницу. Поскольку трафик и данные увеличились (особенно включение изображений), эта модель столкнулась с той же проблемой, что и Диснейленд. Если на странице было много изображений и загрузка заняла много времени, я бы не стал ждать контента и не стал бы возвращаться на этот сайт.

Теперь дни веб-страницы загружаются по-разному. Содержимое загружается, отображается и отображается первым, в то время как другой поток загружает, отображает и отображает изображения. Это значительно улучшает взаимодействие с пользователем, и при наличии желаемого контента я продолжу возвращаться на сайт, и это может превратить мои повторные просмотры страниц в $$$.

В некотором отношении это напоминает ОС реального времени.

Некоторые процессы проходят быстро и помечаются как в реальном времени.

У них есть гарантия, что они получат ресурс в течение определенного периода времени. Они не могут прыгнуть в очередь, но они могут продвинуться! Пока они не используют поездку, другие гости не в режиме реального времени могут использовать ее.

для -Alex-

Это отличные вещи. Disney, по сути, создает две очереди с линейно более низкими тарифами на обслуживание в зависимости от количества распределенных FASTpass.

Короткая очередь FASTpass может быть смоделирована как очередь, которая всегда находится в равновесии для короткого ожидания. Сохранение короткой очереди минимизирует обратную связь между двумя очередями - что хорошо для стохастического моделирования. Другая очередь - это типичная очередь с более низкой скоростью обслуживания.

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

Другая стратегия состоит в том, чтобы минимизировать время ожидания пользователя, а именно строго планировать поездки по предварительной записи, и в этом случае это чистая пакетная очередь, которую легко оптимизировать. Я не думаю, что это сработает в США. :-)

Вы не получаете больше поездок. Линии для непопулярных линий теперь стали длиннее, потому что все больше людей убивают время на них, ожидая, когда их билеты на популярную поездку созреют. Емкость - это вместимость.

«Твиттер в настоящее время очень занят. Пожалуйста, возвращайтесь между 15:00 и 15:15, и мы гарантируем, что вы получите ваши твиты через 5 секунд или меньше».