News FPs cancelled when Hotel room cancelled

[MisterPenguin]

FP+ has royally screwed up WDW. That is the basic fact. Anyone arguing that point please tell me why they aren't using it on their two biggest rides, arguably EVER.

It does many things. It DOES turn you in to two people, regardless of what others say. That's the meaning of "virtual". There is now Me and "Virtual Me" visiting WDW. I can send Virtual Me to go do the arduous task of waiting in a 2 hour long standby line, and then take his place when there is 15 minutes left. VIrtual Me really gets screwed, as he doesn't get to ride anything.

While Virtual Me is waiting, I can wait for another ride, eat, hit the head, or just relax. There are most certainly TWO "me"s there.

Also, FP+, since it makes some rides nearly impossible to ride, pushes the rubes to lower end rides. In large amounts. That is why Pirates didn't have a line for decades, and now is always 30 minutes. People throw in the towel on the big rides, and now get to go experience Philharmagic with NO WAIT. Now THAT's magical.

The core problem at WDW, and especially MK is without a doubt Disney's 19 year run of just hoarding cash and not adding capacity to it's parks that even came close to matching the increase in park attendance. They reaped those rewards for a long time, and now are forced to spend billions on a crowd problem, knowing those billions aren't even going to solve the problem.

H

Thanks for sharing!

 

[flynnibus]

While Virtual Me is waiting, I can wait for another ride, eat, hit the head, or just relax. There are most certainly TWO "me"s there.

If you were able to walk right up to a line and bypass the line... would there still be two 'you' in the park in your view of the world?

The answer is 'no' - you don't actually take up two spots of capacity in the park, you just were able to do so without waiting in a line. FP isn't taking up to spots of capacity either - it just changes how you wait.

The 'spot' you think constitutes a second person is not actually waiting in the line. You've simply subscribed to a deferred or scheduled separate line for an attraction. Thus FP doesn't reduce capacity.. nor add it. What it does is changes how people wait.

Changing how people wait changes their tolerance for waiting... which influences their behavior in waiting for standby lines or not. FP changes the attraction's ability to turnover the standby queue.. thus slowing the pace of that line.

If a traditional line turns over 500 people an hour.. and is maintaining an hours wait. That is 500 people 'soaked up' in that line. When the attraction only turns over 200 people an hour... due to capacity splitting with another line (FP).. that is only 200 people soaked up by that line at any time. That means the attraction isn't taking 300 people off the paths/elsewhere for extended periods. 300 people that hour are churning through attraction much faster and are then taking up space or capacity somewhere else.

They didn't get multiplied... they simply are not getting held up by an attraction for as long. Do that across the board.. and you've hurt the people eating capacity of your park, without changing the attraction capacity at all. Thus.. more crowds.

 

[bUU]

That is the basic fact.

If it was, you wouldn't have been driven to try to declare it by fiat like this.

You don't like FP+. We get it. Message received.

Isn't it past time for people to stop trying to make their personal opinion sound like unequivocal fact. Reasonable people disagree about how FP+ affects them. The whole "people attempting to tell other people how they should feel about something" thing is becoming tiring.

 

[Trackmaster]

How so? You can make the reservations ahead of time, and day of it becomes a virtual queue. Pound the app is not ruining anything as it doesn't effect the reservation system.

Two things:

• It ties up the servers. Disney's servers can barely handle it when people get in, make their reservations and leave, but pounding the app really puts a lot of pressure on the servers that cause a lot of people to crash.
• If it wasn't for pound the app, Disney could release more FP+'s, so that people who didn't know about the trick could get a realistic shot at getting more rides. Or just release the same number, and the stand-by line gets to go faster.

Remember, a 4:1 priority ratio is used between FP+ and stand-by lines. So if everybody is redeeming their FP+, the stand-by line will get out of control.

 

[LuvWDW2]

Realistically, how many people do you think are doing pound the app at one time? Of all my real life Disney friends, you’d be surprised how many don’t know that you can modify a time. So many assume once you book it (at Day 60, 30 or day of) that’s it. Or when they check day of and only see Nemo as available in Epcot at 6pm, think that’s it and don’t check again.
Shoot, there’s people who think you currently have to pay to use FP.

 

[ImperfectPixie]

Two things:

• It ties up the servers. Disney's servers can barely handle it when people get in, make their reservations and leave, but pounding the app really puts a lot of pressure on the servers that cause a lot of people to crash.
• If it wasn't for pound the app, Disney could release more FP+'s, so that people who didn't know about the trick could get a realistic shot at getting more rides. Or just release the same number, and the stand-by line gets to go faster.

Remember, a 4:1 priority ratio is used between FP+ and stand-by lines. So if everybody is redeeming their FP+, the stand-by line will get out of control.

Wait, so they load 1 stand-by for every 4 FP+ holders?

 

[mikejs78]

It ties up the servers.

Hardly. The payload size is so small for this request that I doubt it has much of an impact.

 

[mikejs78]

Wait, so they load 1 stand-by for every 4 FP+ holders?

That number has been thrown about but I'm not sure how accurate it is ...

 

[Trackmaster]

That number has been thrown about but I'm not sure how accurate it is ...

A Cast Member told me that point blank who operates 7DMT. I was wearing my ACE shirt, so we started talking shop about coaster operations. He said that the crew the discretion to load it anywhere between 1:1 to 4:1, with it getting more towards 4:1 as the FP+ line gets more crowded. The goal is to drain the FP+ line as fast as possible.

 

[Touchdown]

I don’t understand why people say that pound the app is cheating it’s not. You are simply constantly checking to see if Disney releases more.

FP+ has certainly changed my touring, as the tier rules and such have made it advantageous to park hop. I’ve noticed Disney seems to give you a leg up on getting a tier 1 FP in a park if you haven’t used one that day, you might not get Frozen, Slinky, SDMT or FOP but everything else is usually possible. Also if I’m rope dropping Epcot I almost never use my FPs there and save them for mid afternoon at my 2nd park as I can hit the big three at rope drop and only risk skipping Spaceship Earth. I’ll sometimes even do it at MK because I can usually do most of Fantasyland (no Peter Pan) and Frontierland/Adventureland in the am and just end my morning seeing Philharmagic and the animatronic shows in am.

 

[networkpro]

Hardly. The payload size is so small for this request that I doubt it has much of an impact.

I'll disagree with you, its not the size of the transaction, its the quantity of the transactions that an infrastructure limiting factor. HTTP is stateless so you have to have some sort of session persistence schema like a cookie or URL attributes.

 

[mikejs78]

I'll disagree with you, its not the size of the transaction, its the quantity of the transactions that an infrastructure limiting factor. HTTP is stateless so you have to have some sort of session persistence schema like a cookie or URL attributes.

I'm not sure what session persistence has to do with a REST request....

Payload size makes all the difference because it goes into the possible number of req/sec. Bigger payloads increase request duration, and higher request duration means fewer requests that can be run in a given unit of time. It's concurrent connections that matter, not number of transactions.

I can, with a trivial amount of work, create a single basic http server capable of tens of thousands of requests per second. In a real production load balanced scenario with multiple servers, http is not usually the limiting factor.

Given Disney's daily throughput of guests, it should not be hard for them (depending on their technology stack) to be able to handle the ~120k-150k guests that are at the parks on any given day.

 

[flynnibus]

I'm not sure what session persistence has to do with a REST request....

Payload size makes all the difference because it goes into the possible number of req/sec. Bigger payloads increase request duration, and higher request duration means fewer requests that can be run in a given unit of time. It's concurrent connections that matter, not number of transactions.

I can, with a trivial amount of work, create a single basic http server capable of tens of thousands of requests per second. In a real production load balanced scenario with multiple servers, http is not usually the limiting factor.

Given Disney's daily throughput of guests, it should not be hard for them (depending on their technology stack) to be able to handle the ~120k-150k guests that are at the parks on any given day.

payload size typically is the most agnostic element of the design... because when dealing with concurrency concerns... bandwidth is the problem most easily solved... with just brute force too. The complexity of the transaction is what matters... and that doesn't track with payload, even tho payload may follow it.

 

[Lensman]

payload size typically is the most agnostic element of the design... because when dealing with concurrency concerns... bandwidth is the problem most easily solved... with just brute force too. The complexity of the transaction is what matters... and that doesn't track with payload, even tho payload may follow it.

Stop or you're going to convince me that I should go work there and help fix this thing.

It seems to me that either way the servers should be able to handle the transaction load unless they've designed the thing to go to the available fastpass database every time - which might actually be the case since they might have decided to reserve the available fastpass slots displayed in order to avoid having the transaction fail when you actually accept an available slot.

 

[mikejs78]

payload size typically is the most agnostic element of the design... because when dealing with concurrency concerns... bandwidth is the problem most easily solved... with just brute force too. The complexity of the transaction is what matters... and that doesn't track with payload, even tho payload may follow it.

Yeah that's a better way of saying it than what I said. Payload size is often an indicator of complexity, but not a bottleneck in and of itself. My main point though is that http in and of itself should not be a limiting factor, and given what this request is actually doing, it shouldn't be terribly complex.

Stop or you're going to convince me that I should go work there and help fix this thing.

It seems to me that either way the servers should be able to handle the transaction load unless they've designed the thing to go to the available fastpass database every time - which might actually be the case since they might have decided to reserve the available fastpass slots displayed in order to avoid having the transaction fail when you actually accept an available slot.

Hopefully they have some kind of caching layer. But even if they did go to the DB every single time, as long as their DB is structured well, is properly indexed, and optimized for that transaction, it shouldn't be an issue...

Then again we are assuming that Nextgen was built correctly ....

 

[larryz]

Thanks for sharing!

What do they say about perception?

Spoiler

Perception is reality

 

[mikejs78]

A Cast Member told me that point blank who operates 7DMT. I was wearing my ACE shirt, so we started talking shop about coaster operations. He said that the crew the discretion to load it anywhere between 1:1 to 4:1, with it getting more towards 4:1 as the FP+ line gets more crowded. The goal is to drain the FP+ line as fast as possible.

And we all know that individual cast members are always the most reliable indicators.

 

[MisterPenguin]

Two things:

• It ties up the servers. Disney's servers can barely handle it when people get in, make their reservations and leave, but pounding the app really puts a lot of pressure on the servers that cause a lot of people to crash.
• If it wasn't for pound the app, Disney could release more FP+'s, so that people who didn't know about the trick could get a realistic shot at getting more rides. Or just release the same number, and the stand-by line gets to go faster.

Remember, a 4:1 priority ratio is used between FP+ and stand-by lines. So if everybody is redeeming their FP+, the stand-by line will get out of control.

I'll disagree with you, its not the size of the transaction, its the quantity of the transactions that an infrastructure limiting factor. HTTP is stateless so you have to have some sort of session persistence schema like a cookie or URL attributes.

Are you sure you know how MDE is configured?

I can't remember who said it, but someone who seemed to be in the know intimated that MDE's tasks are partitioned into different servers. The server that tracks your hotel assignment is partitioned from the server that tracks FPs.

If 'pounding' the FP server is putting a load on the system, then the FP would start to lag, and slow down to a crawl, no? For the most part, even when the system is lagging and chugging trying to pull up an ADR, the FP section is still zipping along.

So, I'm not sold on the idea the FP pounding is responsible for an overall MDE slowdown.

 

[mikejs78]

Are you sure you know how MDE is configured?

I can't remember who said it, but someone who seemed to be in the know intimated that MDE's tasks are partitioned into different servers. The server that tracks your hotel assignment is partitioned from the server that tracks FPs.

If 'pounding' the FP server is putting a load on the system, then the FP would start to lag, and slow down to a crawl, no? For the most part, even when the system is lagging and chugging trying to pull up an ADR, the FP section is still zipping along.

So, I'm not sold on the idea the FP pounding is responsible for an overall MDE slowdown.

That's true. I've never really noticed a slowdowm on the refresh, except when on in park wifi. When switching to my mobile network, it's always pretty quick - and if pounding on it caused bottlenecks, it should slow down or error out.

 

[Hawg G]

If you were able to walk right up to a line and bypass the line... would there still be two 'you' in the park in your view of the world?

The answer is 'no' - you don't actually take up two spots of capacity in the park, you just were able to do so without waiting in a line. FP isn't taking up to spots of capacity either - it just changes how you wait.

The 'spot' you think constitutes a second person is not actually waiting in the line. You've simply subscribed to a deferred or scheduled separate line for an attraction. Thus FP doesn't reduce capacity.. nor add it. What it does is changes how people wait.

Changing how people wait changes their tolerance for waiting... which influences their behavior in waiting for standby lines or not. FP changes the attraction's ability to turnover the standby queue.. thus slowing the pace of that line.

If a traditional line turns over 500 people an hour.. and is maintaining an hours wait. That is 500 people 'soaked up' in that line. When the attraction only turns over 200 people an hour... due to capacity splitting with another line (FP).. that is only 200 people soaked up by that line at any time. That means the attraction isn't taking 300 people off the paths/elsewhere for extended periods. 300 people that hour are churning through attraction much faster and are then taking up space or capacity somewhere else.

They didn't get multiplied... they simply are not getting held up by an attraction for as long. Do that across the board.. and you've hurt the people eating capacity of your park, without changing the attraction capacity at all. Thus.. more crowds.

Most of what you're saying is the same as what I'm saying.

FP did nothing to capacity. I've never said that, because it's an obvious fact capacity is the same. What FP + did was remove a large portion of capacity away from day of guests, and give it out way in advance. And it gives you suggestions for FPs. Many folks will just blindly take those, and then when in the park feel obligated to use them. The power of suggestion is strong to those who really don't know what they're doing.

What that does is get tons of folks in lines that used to not exist, making Small World have a long line after decades of none.

Disney, for decades, wanted their guests to have 9 experiences a day. That is nearly impossible today, unless you do 5 A tickets and 4 B tickets. Disney has convinced even hard core visitors that a week stay, with a couple big rides a day, the stupid trip back to your resort to swim in the afternoon, and then a return to watch fireworks in a massive crowd, is a great plan, and a bargain at $60-70 a day if you stay all week, buying $3.50 waters. And so much more enjoyable than a trip to Universal where you can choose your rides that day, and ride lots of big rides in one day, get free refills on pop and popcorn, and can actually drink the tap water.

However, the Disney parks are so overcrowded, FP+ is needed to prevent once in a lifetime visitors from coming and flat out having miserable times. And that is because since AK has opened, each park has had essentially 2, maybe 3 new rides added, many times replacing old rides, and not increasing capacity. So while attendance has increased probably 40% percent in 19 years, ride capacity has increased less than 10% at most parks.

Disney was forced to announce billions in new rides. But we all know those new rides will have an almost insignificant impact on the crowding issues.