ディズニーのFastPassは有効または有用なキュー理論です


164

ディズニーワールドでは、彼らはファストパスと呼ばれるシステムを使用して、人気のある乗り物の2番目の短いラインを作成します。アイデアは、通常は1時間を超える待機で標準回線で待機するか、指定した時間ブロック(通常は数時間後)に戻って10だけ待機するFastPassを取得できるというものです。分以下。FastPassを使用すると、一度に1つの乗り物だけを「待機」することができます。

私はこの概念の背後にあるキューの理論を理解しようと努めてきましたが、私が見つけた唯一の説明は、それが人々を行列から外し、追加の収益をもたらすもの(ショッピング、食事など)を行うように設計されているということです。

これがFastPassが実装された理由ですか、それともそれが解決する実際のビジター効率の問題がありますか?同様のロジックを適用したソフトウェアアプリケーションはありますか?同様のロジック適用する必要があるソフトウェアアプリケーションはありますか?

ソフトウェアで同様のものを実装するときに発生する問題の1つは、ユーザーがキューを選択することに基づいていることです。ソフトウェアの待機サイクルを高速化します。この理論を適切に適用するには、エンドユーザーの選択を必要とせずに、ニーズに基づいてユーザーを配置するキューを知るのに十分なほどスマートである必要があります。


9
これは素晴らしい質問です!本当にSOの意味するところ。
Gavin Miller

19
問題を探すソリューションの最良の例; P
user37468 2009年

12
ええ、+ 1、ディズニーランドを訪れたときでさえ、優れたプログラマーは興味深い問題に気づくことができます
Tim Post

しかし、彼らが公園を離れるとどうなりますか?:)
Tim Post

バッジ "Great Question"を
ありがとうございます

回答:


36

高速パスラインは、特定の配車待ち行列の総スループットを明らかに増加させることはありませんが、人と配車がリソースである場合のリソーススケジューリングとリソース割り当てには役立ちます。

私が言ったように、あなたはその乗り物のそれ以上の総スループットを作成するつもりはありませんが、他の場所で乗り物が十分に活用されていないかもしれません。これらの乗り物と待つ必要のある乗り物に乗れるようになれば、公園全体の効率を向上させることができます。つまり、乗客定員を下回る乗り物の量を最小限に抑えることです。

コンピュータリソースがアイドル状態で、長時間かかるタスクの実行を待機している場合、このリソースを他の何かに利用することは理にかなっています。その観点からは簡単です。


1
もちろん、ディズニーは実際に乗車の利用率を気にしません。つまり、ディズニーは総訪問者数と、売店で支払う金額を気にします。(続き)
ニックジョンソン

3
ファストパスは両方とも増加する可能性があります:訪問者はファストパスを取得できることを知っているため、戻ってくる可能性が高く、列に並んで待っていたはずの時間に何かを買うことができないでしょう。
ニックジョンソン

ファストパスは、十分に活用されていない乗り物には利用できません。非常に人気のある乗り物で、常に重要な待ち行列があります。
brian d foy 2009年

6
これは、顧客の利益であると同時に、収益の問題でもあります。ファストパスとは、(a)指摘されたとおりに何かを購入し、(b)人々が老朽化するのを避けるために、人々を移動させることです。「ディズニー体験」が永遠に並ぶことと等価になると、ディズニーは負けます。FastPassを握っているときにニッケルを使わなくても、ディズニーとあなたの両方が勝ちます。
Cheeso 2009年

1
実際、ディズニーも訪問者を気にしません。彼らは利益を気にします。
ジェルジAndrasek

38

キューの効率ではなく、蓄積についてです。

ファストパスが機能するのは、キュー内の個々のアイテムが何かを「消費」する際により効率的になるためです。並んで食べ物を待っている人なので、命令の実行を待っているプロセッサのようなキューではありません。

ディズニーランドの人々の場合、それは彼らが彼らの楽しみを最大化することを可能にします

命令を受け入れるプロセッサについて考えてみてください。各命令は、そのタスクを実行するためにキューで実行されるのを待っています。今度はそれを変更します–各命令が命令を実行するのではなく、プロセッサから何かを取得するためにインラインで待機していると想像してください–プロセッサにヒットするたびに、ゴールドスターが与えられます。できるだけ。

Fastpassは、メインプロセッサに戻ってそこからゴールドスターを取得する前に、別のプロセッサに移動して、別のプロセッサにゴールドスターを取得する命令を許可するようなものです。

ディズニーランドのユーザーの場合、彼らは楽しみを持っていること、つまり乗車体験を蓄積することに興味があります。ファストパスは、ユーザーがより短いラインで別のライドを見つけることを可能にすることで最大化を可能にし、より短い時間でより多くを蓄積することができます。


3
キューの最適化の観点からではなく、報酬の最適化の観点からそれを検討することについて、非常に優れたポイントを作成します。公園全体の利用状況を確認することも重要な部分だと思うので、もう1つの答えを選びました。
Nathan Voxland 2009年

21

私はFastPassを試しましたが、これは私がそれを見る方法です:

たとえば、待ち時間が1時間のライドに行ったとします。FastPassにアクセスすると、割り当てられた期間が割り当てられ、すぐにエントリーできることが保証されます。通常は1時間以上経過しています。

人気の乗り物用のFastPassesを入手しました。その間、10〜15 mのキューに入れられ、FastPass仮想キューにいる間に3つの乗り物にキューイングして行くことができました。彼らはまた、いくつかの非常に人気のない乗り物に余分な数えられていないFastPassesを私たちに与えました、それらを使用した場合、より人気のある乗り物に負荷をかけて非常に人気のない乗り物を埋めるでしょう。

次の図は、費やした時間と非高速パスオプションを比較したものです。

速いパス

私には有効なキューイング理論であるように見えます。これにより、期待される待機時間が短いリソースを実行しながら、期待される待機時間が長いリソースをさらに遅延させることができます。


11

FastPassは基本的に、ある種の優先度キューを持つ非ブロッキングビジターを実装します。彼らはブロックせず、眠らず、お金を使います。これは、ジョンが午前11:00に使用し、ジョーが午前11:15(または午前11:01)に使用するために機能します。さて、もし全員が速いパスを持っていれば、ほとんどの訪問者が食べ物や贈り物により多くのお金を費やしている間、通常のラインはずっと速くなります。ディズニーにとって、これはある程度望ましい効果です。

パスはいくつかの仮定を行い、いくつかの制限があります。ファストパスホルダーは少数派であると想定しています。変更された場合、パスを複数の乗り物で機能させる必要があります。サポートされている乗り物は1つだけなので、2人のファストパスホルダーが同時に同じ乗り物を要求することはありません。

ここで、ジョーが順番を決める前に公園を出る可能性があることを考えると、システムを効率的にするために、ある種のビジター「futex」を考え出す必要があります。ジョーが去り、ジョンが早く到着した場合、ジョンは乗ることができました。さらに、ジョンは、なぜ彼の高速パスがnn分早く乗れることを彼に通知しなかったのか疑問に思います。ジョーが本当に面白くなるところです、もしジョーが車から日焼け止めを手に入れるためだけに去って戻ったとしたらどうでしょう?結局のところ、彼のターンは2時間先です。彼がブロックしている間(日焼け止めを手に入れている間に)彼の前に200人以上の人が公園を離れない限り、中断できないタスクです。したがって、その場合、Joeをある種のディスクスリープ、つまり、中断または強制終了できないスリープ状態にします。彼は信号を受け取りません、彼は何も投票していません、彼は公園の外にいます。

これは、ロックフリーの実用的なプログラミングを推進する類の理論です。食事の哲学者の問題と同じくらい興味深い、実際にはもっと。

ディズニーに関しては、これはバグではありません。その特徴は、人々が公園を離れる傾向が少なく、お金を使う傾向があるということです。


ファストパスは、ファストパスの保有者が少数派である想定していません。どのライドでも利用できるファストパスの数には限りがあるため、ファストパスそのグループを少数派に強制します。
brian d foy 2009年

実装がそれを実施するので、概念はそれを仮定します。実装ではなく概念について議論しているのではありませんか?:)
Tim Post

7

通常の列では、乗車までの時間を実際に予測することはできません。あなたは緊張していて、時々アイデアを落とすことを考えています。

FastPassを使用すると、正確に定義された時間内に乗車が行われることを「認識」します。あなたはこれがいつ起こるかについて「確実」であり、あまり頻繁にやめることを考えません。買い物や食事に行き、必要なときに戻ってきます。事前に申し込みをして、こだわりを感じているので帰りそうです。Joel Spolsky は、スターバックスのキューで使用されている同様の取り組みのアイデアについて説明しています

したがって、FastPassは公園と訪問者の両方にとって便利なものです。訪問者はより喜び、彼らが待っている間、公園はそれらをより多く売ることができます。

優れたソーシャルエンジニアリングのほんの一例です。


6

これを非同期プログラミングモデルと比較できると思います。

システムにアクションを実行するように要求すると、後で戻って結果が得られます。

大きな違いは、終了時に呼び出すイベント/コールバックを指定するか、待機の準備ができたときに待機に入る必要があるかです。後で戻ってきて待ち時間が短くなることを保証するように指示するメカニズムを見たことがありません。


5

私には、これは優先キューのようです。

最初にSpeedPassを取ると、優先度が高くなります。次にgeneral line queueSpeedPassポップオフするときに、キュー内で優先度が高くなります。

これが優先キューであることに同意した場合、最も明白なソフトウェア実装はOSスケジューリングです

スケジュールWikiの記事から変更:

ディズニーランドのスケジューラは、主に関係しています:

  • 乗車利用-乗車をできるだけ忙しくします。
  • スループット-時間単位ごとにライドを完了した人数。
  • ターンアラウンド-特定のライドを実行するための時間。
  • 待機時間-待機キューで人が待機していた時間。
  • 応答時間-回線がキューに入れられてから最初の応答が生成されるまでにかかる時間。
  • 公平性-一人一人に等しい乗車時間。

2

私にとってのFastPassのアイデアは、タスク1からNを実行する必要があり、自分自身についての知識に基づいたシステムのソリューションのように見えます(ディズニーでは、子供がテストトラックに乗っている間、テストトラックに十分満足していることを知っているかもしれません。到着するSoarin 'FastPassタイムスライス)タスクNの「FastPass」キューに入るようにスケジュールし、タスクMの標準キューにも入るようにすることができます。これは、タスクの順序が必ずしも重要ではなく、キュー時間がある場合に機能します。既知であり、タスクMまたはNを実行するのにかかる時間を見積もることができました。ただし、実際のプログラミングの良い例があるかどうかはわかりません。私たちの考え方の多くは本質的に線形であり、ワークフローはそのようになる傾向があります。


1

FastPassを使用すると、同時に複数の行で待機できます。待機を回避できますが、行が実質的に長くなるため、平均待機時間が増加します。

しかし、ほとんどの人は自分の時間をライドに費やしていません。パレードなどの一部のイベントでは、実際には待ち時間がありません。高速パスを使用することにより、多くの延縄の乗り物を犠牲にすることなく、これらの無線または短線イベントにさらに行くことができます。


実際、元の投稿では、一度に1つのファストパスしか持てないと述べていました。正しいかどうかはわかっています
ShoeLace

2行はまだ複数行
Craig Gidney

同時に複数の高速パスを使用できます。ただし、最初のファストパスが使用可能になるまで、2番目のファストパスを取得することはできません。使用したことを示すものは何もありません。
brian d foy 2009年

1

私にとって、ソフトウェア開発において同様の振る舞いをしていると思う場所が2つあります。ただし、どちらも必要なため、どちらも正確な類推ではありません

1つは非同期プログラミングです。前述、あなたは待つかの点で、非同期モデルとファストパスモデルの間にいくつかの違いが、あります。ただし、他のいくつかのプログラミングモデル(Message Passing Interfaceなど)には他のいくつかのオプションがあり、おそらくFastPassモデルに少し近づきます。

特に、MPIのMPI_Gatherメソッドについて考えていました。これらのメソッドは、おそらく少し近いモデルを使用しています。すべての関数はクラスターの周りに渡され、ルートから収集を呼び出して、現在処理されているデータを取得できます。目標は同じです(誰もが待たないようにし(ユーザーをブロックしないで)、歩き回って、費やして(またはデータを処理して)います)。

TPLの新しいスケジューラなど、高度なスレッドプログラミングモデルが類似していることがわかります。C#4に含まれるTPLの主な利点の1つは、スケジューラーが作業のスチールを許可することです。これは、動的に行を移動しようとするソフトウェアの明確な実装のように思えます-これはFastPassに結びつきます。ファストパスの優れた点の1つは、列に並ばずに、より多く乗って、さらに動き回ることです。TPLを使用すると、キューが終了したスレッドが他のキューからタスクを盗むことができるため、(できれば)ブロックと待機が少なくなります。


MPI_Gatherについて-同意しますが、FastPassはほとんどのスケジューリング実装で対称性を持っています。
Gavin Miller

1

FastPassの興味深い点の1つは、Disneyのフィードバックチャネルを導入することです。アトラクションが利用可能になるのをほぼ常に待機する単一のラインを用意することで、1日のラインが一定の時間間隔で何とかして測定することを除いて、できることは多くありません。FastPass Disneyを使用すると、アトラクションごとに需要とトラフィックデータがリアルタイムで収集され、すでにデジタル化されています。データウェアハウスに移動してすぐにマイニングを行う必要があります。

FastPassをリソースキューイングシステムよりもリソースアロケーションシステムとして認定する人に同意する傾向があります。もう1つの例えは、すべてのDisneyの顧客を、顧客がFastPassを受け取るまでシングルスレッドのOSプロセスとして扱うことです。これにより、顧客は以前と同様に公園全体を循環し続け、指定されたリソース(FastPassアトラクション)の順番を待つ別のスレッドを実行する2スレッドプロセスになります。ユーザー(プロセス)に複数のFastPassesを許可すると、そのようなプロセスはよりマルチスレッドになります。スレッドの同期は、お客様が最後にFastPassのアトラクションにアクセスして楽しむときに行われます。


ほとんどの乗り物は、すでに1日を通して読み込みをデジタル化できる可能性があります。各シートベルト/ロッキングアームのセンサーは、1回の走行あたりの乗客数をカウントし(さらに、座ったい場所も)、ライドが最も頻繁に、最も多くの負荷が
かかっている

FastPassの乗り物は、ほとんどの場合満員になるため、これは確かに機能しません。
2009年

0

私が見ることができる唯一のソフトウェアの類似点は、この方法がキューバッファーのオーバーフローを回避することです。多くのクライアントがほぼ同時にキューに追加しようとすると、すぐにそのキューがいっぱいになる可能性があります。クライアントが一定の時間待機するように求められた場合、キューに追加する前に、(比較的)少ない数のアイテムをローカルでバッファする必要があります。

ただし、他のほとんどの場合、待機時間が適切に選択されていない場合、キューが不足する可能性があるため、スループットが低下します。

「FastPass」を使用する場合と使用しない場合の両方で、さまざまなメトリックの下でキューイングを使用するテストアプリケーションを作成し、結果を比較してみてください。興味深いものがあれば、お知らせください。:)


0

それがソフトウェアでどのように適用されるかについて知りません。しかし、このシステムには訪問者にとって間違いなく利点があります。1つのライドでファストパスを使用し、その間、ラインが長くない別のライドに行くことができます(つまり、買い物や食事などに行きます)。私と私の家族がそこにいたとき、それはかなりの命の恩人でした(確かに、それはオフシーズンでした)。



0

私のサプライチェーンのクラスから、すぐに私に来たキューイングの側面は、知覚される待機時間が短縮されるため、人々はまったく待機することを気にしません。メインラインが短くなるとは思いませんが、誰かがレギュラーラインで待つことへの不安を和らげます。とにかくタイムアップです)。

ファストパスを使用すれば、さらに多くの乗り物に乗ることができることはわかっていますが、実際にそうであるのか、それとも待機時間の賢い再構成なのかはわかりません。


0

私が見つけた唯一の説明は、それが人々を行列から外し、追加の収入をもたらすことになること(買い物、食べるなど)をするように設計されているということです。

あなたはそこの要点にぶつかったと思いますが、それはおそらくそれが当然のことよりも企業悪に聞こえるようにします。買い物や食事をしているときは、物理的に並んでいるよりも、「事実上並んでいる」ほうがいいです。

理論的には、FastPassは、自然な需要が少ないときに、より多くの人をスケジュールすることを試みました。これが、実際にスケジュールされたキューからより多くのスループットを引き出すために行うことです。しかし、実際には、乗り物は1日のほとんどの容量でほぼ動作していると思うので、これから得られる生産性はほとんどありません。


0

これは、人気のある乗り物のリソーススケジューリングと、商品を販売して追加の収益を生み出す方法についてです。あなたが並んで待っている場合、それはあなたがより多くのお金を使う機会が与えられていないことを意味します。


0

顧客を満足させることはディズニーにとって最大の利益となります。マーチャンダイジングは確かに大きな収益ですが、リピーターを獲得することは何倍も価値があります。

1日のパークホッパーチケットに150ドルを払って、ラインが非常に長いために10回の乗車しか行かない場合、それらの乗車が本当に1枚15ドルの価値があるかどうか疑問に思います。しかし、30の乗り物で行く方法がある場合、私はより良い経験をし、その経験の価値を疑う可能性が低くなり、ディズニーランドにさらに150ドル+食品+商品を与える可能性が高くなります。

FastPassが登場する前は、10回の乗車と30回の乗車の違いは、公園の混み具合だけでした。これは、他の望ましいアトラクションが他の方法で対処しようとした一般的な問題です。たとえば、タホのノーススタースキーリゾートでは、特定の日に販売するリフトチケットの数が制限されます(少なくとも以前は使用されていました)。これは問題にも対処しますが、収益にマイナスの影響を与える方法で対処します。

ソフトウェアでは、同様のパラダイムがWebページをロードします。昔は、このプロセスはシングルスレッドでした。すべてのコンテンツを取得し、すべてのコンテンツをレンダリングして、ページを表示しました。トラフィックとデータが増加するにつれて(特に画像の組み込み)、このモデルはディズニーランドと同じ問題に直面しました。ページに多くの画像があり、ロードに長い時間がかかった場合、私はコンテンツを待たず、そのサイトに再びアクセスすることはありません。

現在、Webページのロード方法は異なります。コンテンツが最初にロード、レンダリング、表示され、別のスレッドが画像をロード、レンダリング、表示します。これにより、ユーザーエクスペリエンスが大幅に向上します。望ましいコンテンツがあれば、引き続きサイトに戻ってきて、繰り返されるページビューを$$$に変えることができます。


0

これは、いくつかの点でリアルタイムOSに似ています。

一部のプロセスには高速パスがあり、リアルタイムとしてマークされています。

彼らは、一定の期間内にリソースを取得することが保証されています。彼らは列に並ぶことはできませんが、押し込むことはできます!ライドを使用していない間は、他の非リアルタイムのゲストがライドを使用できます。

-アレックス


0

これは素晴らしいことです。ディズニーは基本的に2つのキューを作成しており、配信されるFASTpassの数に応じてサービスレートは直線的に低くなります。

短いFASTpassキューは、短い待機の間常に平衡状態にあるキューとしてモデル化できます。キューを短くすると、2つのキュー間のフィードバックが最小限に抑えられます。これは、確率的モデリングに適しています。もう1つのキューは、サービスレートが遅い一般的なキューです。

もちろん、FASTpassクォータが大きくなりすぎると、2つのキュー間のフィードバックが発生し、システムがカオスになり、結果を説明するためのキューイングモデルの影響が最小限になります。

もう1つの戦略は、ユーザーの待機を最小限に抑えることです。厳密には、予約によって配車をスケジュールすることです。この場合、それは純粋なバッチキューであり、最適化が簡単です。それはアメリカではうまくいくとは思いません。:-)


0

あなたはより多くの乗り物に乗りません。人気のある乗車券が成熟するのを待つ間、より多くの人々が時間をつぶしているため、不人気の行の行は長くなりました。容量は容量です。

「Twitterは現在非常に忙しいです。15:00から15:15の間に戻ってください。5秒以内にツイートを取得できることを保証します。」

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.