FastPass Disney's Действительная и/или Полезная Теория Очереди

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

я думаю, что Вы совершили нападки на основном моменте там, но Вы заставляете его звучать более корпоративно-злым, чем, возможно, он заслуживает. Я быть, конечно, бы “virtually queue” при покупках и еде, чем физически очередь в строке.

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

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

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

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

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

Попытка, пишущий тестовое приложение, которое использует организацию очередей и с и без 'FastPass' под различными метриками и сравнением результатов - и сообщает нам, находите ли Вы что-нибудь интересным!:)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скажем, Вы переходите к поездке с расчетным временем ожидания 1 ч, если Вы перейдете к FastPass, то Вы получите присвоенный период времени, где Вам гарантируют непосредственную запись. Это обычно больше чем после 1 ч.

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

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

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

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

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

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

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

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

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

Мне это походит приоритетная очередь .

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

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

ОС, Измененное от планирования статья Wiki:

Земля Disney планировщик затронут главным образом с:

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

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

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

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

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

Насколько Disney идет.. это не ошибка, это - функция, люди менее склонны покинуть парк более склонный тратить деньги.

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

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

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

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

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

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

-Alex

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

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

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

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

Сейчас веб-страницы загружаются по-другому. Контент загружается, обрабатывается и отображается первым, в то время как другой поток загружает, обрабатывает и отображает изображения.