-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Improved recurring event booking speed #9600
fix: Improved recurring event booking speed #9600
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@JaideepGuntupalli is attempting to deploy a commit to the cal-staging Team on Vercel. A member of the Team first needs to authorize it. |
📦 Next.js Bundle Analysis for @calcom/webThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
Thank you for following the naming conventions! 🙏 |
Co-authored-by: alannnc <alannnc@gmail.com>
hey @emrysal, @hariombalhara, @zomars, just a reminder, can you pls review the PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: alannnc <alannnc@gmail.com> Co-authored-by: Hariom Balhara <hariombalhara@gmail.com>
What does this PR do?
This pull request aims to improve the recurring booking speed by optimizing two crucial actions. The time required to perform the first action is directly proportional to the number of recurrences booked.
In the existing code, when 12 recurrences were booked, the first action took approximately 16 seconds.
However, with the changes implemented in this pull request, the same 12 recurrences can be processed in just 9 seconds.
This improvement is achieved by reducing the number of network requests from n to 1. Previously, the frontend code utilized a for loop, increasing network overhead. By streamlining the process, we significantly decrease network requests and payload size, enhancing the booking speed.
Although the network optimizations have been implemented, there is room for further improvement. One area that can be explored is reducing the number of exchanges from the database. It might be possible to create an optimized handler to enhance performance. Additionally, I couldn't find optimizations in the second action, which involves generating a booking success redirect. Further enhancements can be explored to make this action more efficient.
Fixes #9517
Type of change
How should this be tested?
Mandatory Tasks