search

cubehouse / themeparks

Unofficial API for accessing ride wait times and schedules for Disneyland, Disney World, Universal Studios, and many more parks
MIT License
542 stars 125 forks source link

High latency for first GetWaitTimes() call #133

Closed jygrinberg closed 5 years ago

jygrinberg commented 5 years ago

Park Disney parks in the USA

Context

Describe the bug First of all, thanks for an incredible API! It's built quite well.

I'm trying use the API in a Google Cloud Function and am getting strange behavior. I find that the first call to GetWaitTimes() takes ~20 seconds, then subsequent calls take ~2 seconds. Do you know why that might be? Perhaps is there some caching that happens during the first call? If so, any ideas how I can avoid this issue? After 10 minutes or so, the issue recurs and the next call to GetWaitTimes() takes ~20 seconds.

This happens for all the parks I've tried, namely the Disney parks in the USA.

Strangely, when running the same code on my personal machine, I do not encounter the issue. The issue could be with Google Cloud Functions, though I've used Google Cloud Functions for making RPCs to other endpoints without any issues.

Thanks! Josh

P.S. I'm building the "Disney Times" action for Google Assistant. It's only possible thanks to your API :) https://assistant.google.com/services/a/uid/0000007ba68d6575?hl=en-US Let me know if there's anything else I can do to cite your API in the action description at the link above.

cubehouse commented 5 years ago

Hi,

All parks behave differently, but most have a multiple step process:

Once we've done this once, we cache the first two steps in memory (for how long depends on the park implementation), so further requests will be significantly faster.

Because of this, the API won't perform well in lambda scenarios like Google Cloud Functions, since (as I understand) each time the script is accessed it is a fresh instance of the application in memory.

In fact, Disney are now using a brand new API for their parks that requires a live connection to their systems to receive real time updates (this is in the beta version of this library, version 5), so "serverless" deployments are going to get even less efficient I fear.

Ideally you should be running a single instance of this library that makes regular updates and stores the results, then the API simple regurgitates the response, rather than manually fetching each time your API is hit.

I hope that helps to explain a little how the library behaves!

jygrinberg commented 5 years ago

Got it. Thanks for such a detailed response! I'll see what I can do to introduce state into my app.