[#1111] Book calls fail during load test

Bug Reports
,
1

Migrated from Redmine #1111 | Author: Grant Spilsbury
Status: New | Priority: Immediate, there is BUG! | Created: 2023-09-26

During a load test of our system we found Simplybook calls started returning errors when we increased the speed / frequency of booking (/book) requests.
Our script simulated multiple users trying to make bookings with random delays between requests. This likely resulted in 2 users trying to book the same slot at the same time (but we set up each slot to have 99 availabilities). We have made the assumption that these simultaneous booking requests are the reason for the errors from Simplybook.

url: ‘https://user-api.bookings.vicinity.com.au’,
X-Company-Login: ‘chadstone’,

We ran 2 tests on 2 different days

Test 1 (log filename: full_logs.txt)

Test Parameters
Visitors / users: 400
Booking attempts: 200 (50% of visitors)
Duration of test: 60 seconds
Event URL: https://chadstone.testing.centre-websites.vcx.cloud/channels/website/pages/testing/testing-volumes?_storyblok=357910752&_storyblok_c=website_component_page&_storyblok_tk[space_id]=62672&_storyblok_tk[timestamp]=1692667852&_storyblok_tk[token]=6eaef83bf127c2142329d4bba251c68218786783&_storyblok_version=&_storyblok_lang=default&_storyblok_release=0

Test results
Failure rate: 80%
Time of test: Tue, 29 Aug 2023 12:39:45 GMT

Test 2 (log filename: full_logs2.txt)

Test Parameters
Visitors / users: 396
Booking attempts: 198 (50% of visitors)
Duration of test: 60 seconds
Event date: 1 November 2023 (this date has 2 slots with 99 capacity available for each slot)
Event URL: https://chadstone.testing.centre-websites.vcx.cloud/channels/website/pages/testing/testing-volumes?_storyblok=357910752&_storyblok_c=website_component_page&_storyblok_tk[space_id]=62672&_storyblok_tk[timestamp]=1692667852&_storyblok_tk[token]=6eaef83bf127c2142329d4bba251c68218786783&_storyblok_version=&_storyblok_lang=default&_storyblok_release=0

Test results
Failure rate: 52%
Time of test: Thu, 21 Sep 2023 09:47:20 GMT

2

Redmine Admin wrote:

hi, if you have 99 slots and try to book 200 times then it is fine to get 50% of failure rates because slot will not be available anymore

3

Alex Alex wrote:

Hi,
about the test, there were 2 slots available 9:00 - 09:25 and 09:25 - 09:50 on November 1st.
the script that ran a loading test was randomizing the start time between those 2.
Appointment booking service and free online booking service here is the class that was booked.
In total, it created 95 bookings when looking at the booking details report. 47 bookings for 9:00 AM and 48 for 09:25 AM.
Here is the response log from the last test bookings

4

Grant Spilsbury wrote:

Redmine Admin wrote:

hi, if you have 99 slots and try to book 200 times then it is fine to get 50% of failure rates because slot will not be available anymore

Each time had 99 slots (total of 198 slots)

5

Redmine Admin wrote:

hi, as I wrote you already you are trying to make bookings for exactly same time, service and provider at same moment. To make a load test correct you have 2 ways:

  1. Make provider with just one slot and book his available time with 100-200 parallel requests.
  2. If there are more than 1 slot per provider and you want to book all this slots than make sure you have at least 50-100ms gap between calls. Parallel calls will cause error above
6

Grant Spilsbury wrote:

Redmine Admin wrote:

hi, as I wrote you already you are trying to make bookings for exactly same time, service and provider at same moment. To make a load test correct you have 2 ways:

  1. Make provider with just one slot and book his available time with 100-200 parallel requests.
  2. If there are more than 1 slot per provider and you want to book all this slots than make sure you have at least 50-100ms gap between calls. Parallel calls will cause error above

Alex is telling us different. Please see images attached. Alex please can you discuss and confirm this limitation.

7

Redmine Admin wrote:

that’s why we have this API support forum. It is always better to discuss issues directly with developers.