ディズニーのFastPassは有効または有用なキュー理論です
ディズニーワールドでは、彼らは Fastpass と呼ばれるシステムを使用して、人気のある乗り物の2番目の短いラインを作成します。アイデアは、標準的なラインで待機することができ、多くの場合1時間以上待機するか、または指定された時間ブロック（通常は数時間後）に戻って10だけ待機するFastPassを取得できるということです。分以下。 FastPassを使用すると、一度に1つの乗り物だけを「待つ」ことができます。
私はこの概念の背後にあるキューの理論を理解しようと試みましたが、私が見つけた唯一の説明は、人々を列から離し、追加の収入をもたらすこと（買い物、食事など）を行うように設計されているということです。
これがFastPassが実装された理由ですか、それともそれが解決する実際のビジター効率の問題がありますか？同様のロジックを適用したソフトウェアアプリケーションはありますか？同様のロジックを適用する必要があるソフトウェアアプリケーションはありますか？
ソフトウェアで同様のものを実装するときに私が目にする問題の一部は、ユーザーがキューを選択することに基づいているということです。ソフトウェアの待機サイクルを高速化します。この理論を適切に適用するには、エンドユーザーの選択を必要とせずに、ニーズに基づいてユーザーを配置するキューを知るのに十分にスマートなアプリケーションが必要になると思います。
高速パスラインは、特定の配車キューの総スループットを増加させることはありませんが、人と配車がリソースである場合のリソーススケジューリングとリソース割り当てには役立ちます。
私が言ったように、あなたはその乗り物のそれ以上の総スループットを作成するつもりはありませんが、他の場所で乗り物が十分に活用されていないかもしれません。これらの乗り物と待機する必要がある乗り物に乗れるようになった場合は、公園の全体的な効率を向上させることができます。つまり、乗客定員を下回る乗り物の量を最小限に抑えるということです。
コンピューターリソースがアイドル状態で、長時間かかる可能性のあるタスクの実行を待機している場合、当面はこのリソースを他の何かに利用することは理にかなっていますか？その観点からは簡単です。
キューの効率ではなく、蓄積についてです。
ファストパスが機能するのは、キュー内の個々のアイテムが何かを「消費」する際により効率的になるためです。並んで食べ物を待っている人なので、命令の実行を待っているプロセッサのようなキューではありません。
ディズニーランドの人々の場合、それは彼らが彼らのfunを最大化することを可能にします。
命令を受け入れるプロセッサについて考えてみてください。各命令は、そのタスクを実行するためにキューで実行されるのを待っています。今度は変更してください–各命令が命令を実行するのではなく、インラインで待っていると想像してくださいgetプロセッサからの何か–プロセッサにヒットするたびに、ゴールドスターとその仕事が報われますこれらをできるだけ多く蓄積することです。
Fastpassは、メインプロセッサに戻ってそこからゴールドスターを取得する前に、別のプロセッサに移動して、別のプロセッサにゴールドスターを取得する命令を許可するようなものです。
ディズニーランドのユーザーの場合、彼らは楽しみを持っていること、つまり乗車体験を蓄積することに興味があります。ファストパスは、ユーザーがより短いラインで別のライドを見つけることを可能にすることで最大化を可能にし、より短い時間でより多くを蓄積することができます。
私はFastPassを試しましたが、これは私がそれを見る方法です：
たとえば、待ち時間が1時間のライドに行ったとします。FastPassにアクセスすると、割り当てられた期間が割り当てられ、すぐにエントリーできることが保証されます。通常は1時間以上経過しています。
人気の乗り物用のFastPassesを入手しました。その間、10〜15 mのキューに入れられ、FastPass仮想キューにいる間に3つの乗り物にキューイングして行くことができました。彼らはまた、いくつかの非常に人気のない乗り物に追加の数えられていないFastPassesを与えました、それらを使用した場合、より人気のある乗り物に負荷をかけ、非常に人気のない乗り物を埋めます。
以下は、費やした時間と非高速パスオプションを比較した図です。
私には有効なキューイング理論であるように見えます。これにより、期待待機時間が短いリソースを実行しながら、期待待機時間が長いリソースをさらに遅延させることができます。
FastPassは基本的に、ある種の優先度キューを持つ非ブロッキングビジターを実装します。彼らはブロックせず、眠らず、お金を使います。これは、ジョンが午前11:00に使用し、ジョーが午前11:15（または午前11:01）に使用するために機能します。さて、もし全員が速いパスを持っていれば、ほとんどの訪問者が食べ物や贈り物により多くのお金を費やしている間、通常のラインははるかに速くなります。ディズニーにとって、これはある程度望ましい効果です。
パスはいくつかの仮定を行い、いくつかの制限があります。それは、ファストパスホルダーが少数派であると想定しています..それが変更された場合、パスを複数のライドで機能させる必要があります。 1つのライドのみがサポートされているため、2人のファストパスホルダーが同時に同じライドを要求することはありません。
ジョーが順番を決める前に公園を離れる可能性があることを考えると、システムを効率的にするために、ある種のビジター「futex」を考え出す必要があります。ジョーが去り、ジョンが早く到着した場合、ジョンは乗ることができました。さらに、ジョンは、なぜ彼の高速パスがnn分早く乗れることを彼に通知しなかったのか疑問に思います。ジョーが本当に面白くなるところです、もしジョーが車から日焼け止めを手に入れるために去って戻ったらどうしますか？結局のところ、彼の番は2時間先です。彼がブロックしている間（日焼け止めを手に入れている間に）彼の前に200人以上の人が公園を離れない限り、中断できないタスクです。したがって、その場合、Joeをある種のディスクスリープ、つまり、中断または強制終了できないスリープ状態にします。彼は信号を受け取りません、彼は何も投票していません、彼は公園の外にいます。
これは、ロックフリーの実用的なプログラミングを推進する類の理論です。 食事の哲学者の問題 と同じくらい興味深い、実際にはもっと。
ディズニーに関しては、これはバグではありません。その特徴は、人々が公園を離れる傾向が少なく、お金を使う傾向があるということです。
通常の列では、実際に乗車する速さを実際に見積もることはできません。あなたは緊張していて、時々アイデアを落とすことを考えています。
FastPassを使用すると、正確に定義された時間内に乗車が行われることを「認識」します。あなたはこれがいつ起こるかについて「確信を持って」おり、あまり頻繁にやめないことを考えています。買い物や食事に行き、必要なときに戻ってきます。事前に申し込みをして、こだわりを感じているので帰りそうです。 Joel Spolsky スターバックスのキューで使用されている同様の取り組みのアイデアを説明しています 。
したがって、FastPassは、公園と訪問者の両方にとって一種の便利さです。訪問者はより喜び、彼らが待っている間、公園はそれらをより多く売ることができます。
優れたソーシャルエンジニアリングのほんの一例です。
これを 非同期プログラミングモデル と比較できると思います。
システムにアクションを実行するように要求すると、後で戻って結果が得られます。
大きな違いは、終了時に呼び出すイベント/コールバックを指定するか、待機の準備ができたときに待機に入ることを要求されることです。後で戻ってきて待ち時間が短くなることを保証するように指示するメカニズムを見たことがありません。
私にはこれは priority queue のように見えます。
SpeedPassを最初に取得すると、より高い優先度が達成されます。次に、general line queueSpeedPassは、キュー内でより優先されます。
そして、これが優先キューであることに同意している場合、最も明白なソフトウェア実装は OSスケジューリング です。
スケジュールWikiの記事から変更：
Disney Landスケジューラーは主に以下に関係しています：
- 乗車利用-乗車をできるだけ忙しくします。
- スループット-時間単位ごとにライドを完了した人数。
- ターンアラウンド-特定のライドを実行するための時間。
- 待機時間-人がレディキューで待機していた時間。
- 応答時間-回線がキューに入れられてから最初の応答が生成されるまでにかかる時間。
- 公平性-一人一人に等しい乗車時間。
FastPassのアイデアは、1からNのタスクを実行する必要があり、自分自身についての知識に基づいたシステムのソリューションのように見えます（ディズニーでは、子供がテストトラックに十分に乗ることができると知っているかもしれません。 SoarinのFastPassタイムスライスが到着するのを待つ間）タスクNの「FastPass」キューに入るようにスケジュールし、タスクMの標準キューにも入るようにすることができます。これは、タスクの順序が異なる場合に機能します」 tは必ずしも重要であり、待ち行列時間がわかっていて、タスクMまたはNを実行するのにかかる時間を見積もることができました。ただし、実際のプログラミング例が適切かどうかはわかりません。私たちのワークフローはそのようになる傾向があります。
FastPassを使用すると、同時に複数の行で待機できます。待機を回避できますが、行が実質的に長くなるため、平均待機時間が増加します。
しかし、ほとんどの人は乗り物に行くことに時間を費やしていません。パレードなどの一部のイベントでは、実際には待ち時間がありません。高速パスを使用することにより、多くの延縄の乗り物を犠牲にすることなく、これらの無線または短線イベントにさらに行くことができます。
私にとってソフトウェア開発において同様の振る舞いをしていると思う場所が2つあります。ただし、どちらも必要なため、どちらも正確な類推ではありません
1つは非同期プログラミングです。 前述 と同様に、待機モデルに関して、非同期モデルとファストパスモデルの間にはいくつかの違いがあります。ただし、他の一部のプログラミングモデル（ Message Passing Interface など）には他のいくつかのオプションがあり、おそらくFastPassモデルに少し近づきます。
特に、MPIのMPI_Gatherメソッドを考えていました。これらのメソッドはおそらくもう少し近いモデルを使用しています。すべての関数はクラスターの周りに渡され、その後、現在処理されているデータを取得するためのrootです。目標は同じです（誰もが待たないようにし（[ユーザーをブロックしない]）、歩き回り、[またはデータを処理する]ことです）。
[〜＃〜] tpl [〜＃〜] の新しいスケジューラなど、類似性を確認できるもう1つの場所は、高度なスレッドプログラミングモデルです。 C＃4に含まれるTPLの主な利点の1つは、スケジューラーが作業のスチールを許可することです。これは、動的に行を移動しようとするソフトウェアでの明確な実装のように思えます。これはFastPassに関連付けられます。ファストパスの良い点の1つは、列に並ばずに、より多く乗って、より多くの場所に移動できることです。 TPLを使用すると、キューが完了したスレッドが他のキューからタスクを盗むことができるため、ブロッキングと待機が（うまくいけば）少なくなります。
FastPassの興味深い点の1つは、Disneyのフィードバックチャネルを導入することです。アトラクションが利用可能になるのをほぼ常に待機する単一のラインを使用することで、1日の間に一定の時間間隔でラインがどれだけ長いかを測定することを除いて、実行できることはほとんどありません。 FastPass Disneyを使用すると、アトラクションごとに需要とトラフィックのデータがリアルタイムで収集され、すでにデジタル化されています。データウェアハウスに移動して、すぐにマイニングを行う必要があります。
FastPassをリソースキューイングシステムよりもリソースアロケーションシステムとして認定する人に同意する傾向があります。別の例えは、すべてのDisneyの顧客を、顧客がFastPassを受け取るまでシングルスレッドのOSプロセスとして扱うことです。これにより、以前のように公園全体を循環し続け、指定されたリソース（FastPassアトラクション）の順番を待つ別のスレッドを実行する2スレッドプロセスが顧客に提供されます。ユーザー（プロセス）に複数のFastPassesを許可すると、そのようなプロセスはよりマルチスレッドになります。スレッドの同期は、お客様が最後にFastPassの魅力に到達してそれを楽しむときに行われます。
私が見ることができる唯一のソフトウェアの類推は、この方法がキューバッファのオーバーフローを回避することです。多くのクライアントがほぼ同時にキューに追加しようとすると、すぐにそのキューがいっぱいになる可能性があります。クライアントが一定時間待機するように求められた場合、キューに追加する前に、（比較的）少ない数のアイテムをローカルでバッファする必要があります。
ただし、他のほとんどの場合、待機時間が適切に選択されていない場合、キューが不足する可能性があるため、スループットの効率が低下します。
「FastPass」を使用する場合と使用しない場合の両方で、さまざまなメトリックの下でキューイングを使用するテストアプリケーションを作成し、結果を比較してみてください。興味深いものがあれば、お知らせください。 :)
それがソフトウェアにどのように適用されるかについて知りません。しかし、このシステムには訪問者にとって間違いなく利点があります。1つのライドでファストパスを使用し、その間、ラインが長くない別のライドに行くことができます（または、あなたが言うように、買い物や食事などに行きます）。私と私の家族がそこにいたとき、それはかなりの命の恩人でした（確かに、それはオフシーズンでした）。
悪用されている であることを考えると、キューユーザーを信頼する必要があります;-)
私のサプライチェーンのクラスから、すぐに私に来たキューイングの側面は、知覚される待機時間が短縮されるため、人々はまったく待機することを気にしません。メインラインが短くなるとは思いませんが、誰かがレギュラーラインで待つことに対する不安を和らげます、なぜなら彼らは彼らが乗り降りたらすぐに彼らがもう一度戻ることができることを知っているからです（彼らのファーストパスならとにかくタイムアップです）。
ファストパスでもっと多くの乗り物に乗ることができることは知っていますが、それが実際にそうであるのか、それとも私の待ち時間の賢い再構成なのかはわかりません。
顧客を満足させることはディズニーにとって最大の利益です。マーチャンダイジングは確かに大きな収益ですが、リピーターを獲得することは何倍も価値があります。
1日のパークホッパーチケットに150ドルを払って、ラインが非常に長いために10回の乗車しか行かない場合、それらの乗車が本当に1枚15ドルの価値があるかどうか疑問に思います。ただし、30回のライドに行く方法がある場合は、私はより良い経験をし、その経験の価値を疑う可能性が低くなり、ディズニーランドにさらに150ドル+食品+商品を与える可能性が高くなります。
FastPassが登場する前は、10回の乗車と30回の乗車の違いは、公園の混み具合だけでした。これは、他の望ましいアトラクションが他の方法で対処しようとした共通の問題です。たとえば、タホのノーススタースキーリゾートでは、特定の日に販売するリフトチケットの数が制限されます（少なくとも以前は使用されていました）。これは問題にも対処しますが、収益にマイナスの影響を与えます。
ソフトウェアでは、同様のパラダイムがWebページをロードします。昔は、このプロセスはシングルスレッドでした。すべてのコンテンツを取得し、すべてのコンテンツをレンダリングして、ページを表示しました。トラフィックとデータが増加すると（特に画像の組み込み）、このモデルはディズニーランドと同じ問題に直面しました。ページに多くの画像があり、ロードするのに長い時間がかかった場合、私はコンテンツを待たず、そのサイトに戻ることはありません。
現在、Webページのロード方法は異なります。コンテンツが最初にロード、レンダリング、表示され、別のスレッドが画像をロード、レンダリング、表示します。これにより、ユーザーエクスペリエンスが大幅に向上します。望ましいコンテンツがあれば、引き続きサイトに戻ってきて、繰り返されるページビューを$$$に変えることができます。
これは素晴らしいことです。 Disneyは基本的に2つのキューを作成しており、配信されるFASTpassの数に応じてサービスレートは直線的に低くなります。
短いFASTpassキューは、短い待機の間常に平衡状態にあるキューとしてモデル化できます。キューを短くすると、2つのキュー間のフィードバックが最小限に抑えられます。これは、確率的モデリングに適しています。もう1つのキューは、サービスレートが遅い一般的なキューです。
もちろん、FASTpassクォータが大きくなりすぎると、2つのキュー間のフィードバックが発生し、システムがカオスになり、結果を説明するためのキューイングモデルの影響が最小限になります。
もう1つの戦略は、ユーザーの待機を最小限に抑えることです。厳密に予約によって配車をスケジュールすることです。その場合、それは純粋なバッチキューであり、最適化が簡単です。それはアメリカではうまくいくとは思いません。 :-)
これは、いくつかの点でリアルタイムOSに似ています。
一部のプロセスには高速パスがあり、リアルタイムとしてマークされています。
彼らは、一定の期間内にリソースを取得することが保証されています。彼らはキューにジャンプすることはできませんが、プッシュインできます！ライドを使用していない間は、他の非リアルタイムのゲストが使用できます。
-アレックス
これは、人気のある乗り物のリソーススケジューリングと、商品を販売して追加の収益を生み出す方法についてです。あなたが並んで待っている場合、それはあなたがより多くのお金を使う機会が与えられていないことを意味します。
私が見つけた唯一の説明は、それが人々を行列から外し、追加の収入をもたらすことになること（ショッピング、食事など）をするように設計されているということです。
あなたはそこの主要な点にぶつかったと思いますが、それはおそらくそれが値するよりも企業悪に聞こえるようにします。私は確かに、買い物や食事をしている間は、物理的に並んでいるよりも「事実上並んでいる」ことを望んでいます。
理論的には、FastPassは、自然な需要が少ないときに、より多くの人をスケジュールすることを試みました。これが、実際にスケジュールされたキューからより多くのスループットを引き出すために行うことです。しかし、実際には、乗り物は1日のほとんどの容量でほぼ動作していると思います。そのため、これから得られる生産性はほとんどありません。
あなたはより多くの乗り物に乗りません。人気のある乗車券が成熟するのを待つ間、より多くの人々が時間をつぶしているため、不人気の行の行が長くなりました。容量は容量です。
「Twitterは現在非常に忙しいです。15：00から15:15の間に戻ってください。5秒以内にツイートを取得できることを保証します。」