Skip to content
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

Allow for higher sync rate for subsciption calendars #46171

Open
1 of 5 tasks
miaulalala opened this issue Jun 27, 2024 · 11 comments
Open
1 of 5 tasks

Allow for higher sync rate for subsciption calendars #46171

miaulalala opened this issue Jun 27, 2024 · 11 comments
Labels
1. to develop Accepted and waiting to be taken care of enhancement feature: caldav Related to CalDAV internals

Comments

@miaulalala
Copy link
Contributor

miaulalala commented Jun 27, 2024

@tcitworld wrote:

The Nextcloud server caches the subscriptions (stores data in the database) and exposes them as regular calendars. The default refresh rate for this is of one week, which is appropriate for things like public holiday calendars, but might not be for other things, for instance subscribing to a public calendar from another Nextcloud user, and expecting real-time sync.

This high refresh rate makes sense because on servers with a lot of users and subscriptions, the cron would keep wasting time refreshing calendars for nothing, and there could be a risk of the subscription source blocking the server's IP. For instance, as subscriptions can't be shared (or provided by the admin), if all 10 000 users from a company need to subscribe to the holiday calendar from their local government, that's 10 000 requests you need to make every X minutes/hours/days when the original calendar data only changes once or twice a year.

Nextcloud supports properties available for the subscription source to tell what's the appropriate refresh rate (X-PUBLISHED-TTL, REFRESH-INTERVAL), but in practice no-one provides them.

I think there's an issue about providing the setting to select an appropriate refreshment rate for each subscription to end-users in calendar, which would kinda solve most of the issue, though there's a risk users could abuse it, so a minimal rate setting for the admin would be nice as well. In any case, that's not the current state.

So on the other hand, clients have no issue with refreshing the local subscription every 15 minutes/hour/day or even each time the app is opened, as it's only doing it for a single user and from a dedicated IP address.

Therefore, people who would have been forced to manually add the subscription on their device before this change and will now just used the exposed subscriptions from the NC server may have the impression that subscriptions don't get updated when they expect it.


We should take a delta of calendar events and only update those events that have changed.

We should also update all calendars that have the same subscription URI (ex: holiday calendars) at the same time so we only need one run for these calendars.

Work packages

Follow-ups

@miaulalala miaulalala added enhancement 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Jun 27, 2024
@ChristophWurst
Copy link
Member

@miaulalala can this be broken down into manageable chunks? E.g.

  1. Efficient subscription sync (delta sync)
  2. Adaptive/configurable sync intervals
  3. Bulk sync for identical URIs

@miaulalala miaulalala added 1. to develop Accepted and waiting to be taken care of and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Jul 8, 2024
@miaulalala
Copy link
Contributor Author

@miaulalala can this be broken down into manageable chunks? E.g.

1. Efficient subscription sync (delta sync)

2. Adaptive/configurable sync intervals

3. Bulk sync for identical URIs

Yes, that sounds reasonable! Shall I open work package tickets for each?

@ChristophWurst
Copy link
Member

yes please

@ChristophWurst
Copy link
Member

Efficient subscription sync (delta sync)

Tracked in #43541 more or less

@ChristophWurst ChristophWurst moved this to 🏗️ In progress in 💌 📅 👥 Groupware team Jul 25, 2024
@ChristophWurst ChristophWurst added 2. developing Work in progress and removed 1. to develop Accepted and waiting to be taken care of labels Jul 25, 2024
@miaulalala
Copy link
Contributor Author

miaulalala commented Jul 30, 2024

@ChristophWurst
Copy link
Member

If the service exposes a sync interval, use that.
Otherwise allow the user to set the interval.

This part of the feature is tracked in nextcloud/calendar#6187.

@joshtrichards joshtrichards added the feature: caldav Related to CalDAV internals label Aug 2, 2024
@miaulalala
Copy link
Contributor Author

I don't think we need #46687 any more - it's a case of YAGNI

@ChristophWurst
Copy link
Member

ChristophWurst commented Oct 2, 2024

Removed from the work packages

@miaulalala miaulalala removed their assignment Nov 5, 2024
@ChristophWurst ChristophWurst self-assigned this Nov 5, 2024
@ChristophWurst ChristophWurst added 1. to develop Accepted and waiting to be taken care of and removed 2. developing Work in progress labels Nov 5, 2024
@ChristophWurst ChristophWurst moved this from 🏗️ In progress to 📄 To do in 💌 📅 👥 Groupware team Nov 5, 2024
@ChristophWurst ChristophWurst removed their assignment Nov 5, 2024
@ChristophWurst ChristophWurst moved this from 📄 To do to 🧭 Planning evaluation in 💌 📅 👥 Groupware team Nov 5, 2024
@tcitworld
Copy link
Member

tcitworld commented Nov 20, 2024

In the meantime until #46723 is achieved, maybe we can set the default for calendarSubscriptionRefreshRate to one day instead of one week?

@ChristophWurst
Copy link
Member

That sounds reasonable 👍

tcitworld added a commit that referenced this issue Nov 20, 2024
… day

With the performance benefits from #43541 it makes sense

Reference #46171 (comment)

Signed-off-by: Thomas Citharel <[email protected]>
tcitworld added a commit that referenced this issue Nov 20, 2024
… day

With the performance benefits from #43541 it makes sense

Reference #46171 (comment)

Signed-off-by: Thomas Citharel <[email protected]>
@tcitworld
Copy link
Member

See #49396

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of enhancement feature: caldav Related to CalDAV internals
Projects
Status: 🧭 Planning evaluation
Development

No branches or pull requests

4 participants