Migrated from Redmine #1289 | Author: Thomas Luzat Status: Feedback | Priority: High, I’m very impatient | Created: 2024-10-08
We did get recent response times from getStartTimeMatrix (well below 1-2s) in the past, but recently times went up and a single getStartTimeMatrix request takes about 3s to 10s, which breaks our custom booking form.
I assume one of two things happened:
Our user’s requests are being throttled. I tested locally and still get huge times, so it’s probably not dependent on the IP address.
The API got slower.
We are using getStartTimeMatrix from a server with a fixed IP to construct a custom booking form. All requests are coming from that server.
We query the calendar for a whole month by passing the from/to dates and all services to getStartTimeMatrix ([ ‘2025-02-01’, ‘2025-02-28’, 1 ], …, [ ‘2025-02-01’, ‘2025-02-28’, 98 ], …) with some time in between the requests (throttling on our side). We then cache the results for same time.
We need a quick solution to get any sales in; this is currently costing us hundreds if not thousands of €.
I will try to reduce the number of required calls further, but this is still too slow.
If our user is being throttled currently, could the throttling be reset while we are working on optimizations?
Also experiencing this, also impacting revenue. We’re making the same call to getStartTimeMatrix that we’ve been making for months, and haven’t changed anything.
The calls on that public page seem to work well enough (~300ms to get slots for a single day for one service).
Given that our flow is different and we need to try to minimize API requests because of the daily API limits, we would prefer if getStartTimeMatrix (or a similar method) could get those results in fast enough.
This call takes about 4 seconds. This may not be an error, but it has gotten much slower recently, such that it doesn’t work well for interactive use cases. Reducing the query to a single day is still quite slow at about 700ms.
Hi, as mentioned, we are experiencing the same issue.
Totally accept that loading a whole month of availabilities is an expensive operation. What’s confusing me is that the behavior has definitely changed recently, and is not consistent between services.
Are you able to comment on the time complexity of this API with respect to providers/slots? Is there any index of availabilities you maintain or should I expect load times to increase proportionately to the number of providers/slots?
Or, if unable to provide any of that: did you release any changes to this API in the last 2 weeks?
ah okay, I always assumed there was some index maintained. thanks!
So to confirm:
No changes made to the API recently that could be responsible for this
startTimeMatrix API response times are proportionate to the complexity of the schedule (fair enough)
it is pure coincidence that myself and Thomas Luzat experience this today (reported by a customer to us this morning)
Can you confirm these are all true? Then I would proceed with investigation on my side with the colleagues who set up the schedules, and see what we can optimize there.
okay, thank you! Surprisingly, the issue has now resolved itself (with no action from us). Not sure if this is true for @Thomas Luzat too or not, but for the record: we experienced slow load times today that are now gone with no changes from our side.