[Tickets #13279] Re: Improve caching of events in daily / weekly view

[noreply at bugs.horde.org]

BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE  
E-MAIL-ADRESSE WERDEN NICHT GELESEN.

Ticket-URL: https://bugs.horde.org/ticket/13279
------------------------------------------------------------------------------
  Ticket           | 13279
  Aktualisiert Von | Jan Schneider <jan at horde.org>
  Zusammenfassung  | Improve caching of events in daily / weekly view
  Warteschlange    | Kronolith
  Version          | Git master
  Typ              | Enhancement
  Status           | Feedback
  Priorität        | 1. Low
  Milestone        |
  Patch            |
  Zuständige       |
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2016-01-28 12:53) hat geschrieben:

>> Are you talking about client-side or server-side caching? We only
>> cache Kolab data server-side, the client-side cache is independent
>> from the backend and doesn't persist sessions.
>> Of course "zooming in" to calendar views is quicker than zooming out
>> or navigation forth or back. Pre-fetching doesn't make much sense,
>> because you might fetch data which you will never use resp. display,
>> and there is typical navigation pattern like in IMP that we could use
>> to predict that data we might need next.
>
> yes, client side caching is probably what I had in mind.
> I guess you mean there is *no* typical pattern like in imp.
>
> Let me give you an example:
> Changing the current day view in our company wide calendar takes  
> about three to four seconds (using a Kolab backend). Kronolith  
> starts up with the current work week if you enter it for the first  
> time.
>
> When I change to the year view first, it takes about four seconds to  
> load the calendar for the whole year. Now I change back to the week  
> view. It only takes one second to flip through different weeks now.
>
> The Kolab backend is not every efficient when it needs to load only  
> parts of a calendar.
> Even if we add an index to the event data, it still does a lot of  
> backend hits as it checks for new shares (IMAP folders) and so on.  
> That results in four IMAP logins on the server.
>
> May be we can build some kind of optional prefetch that can be  
> disabled by a pref?

This isn't anything that should be decided based on a user preference.

The problem is with any backend that allows to retrieve partial data.  
Backends like Kolab or WebDAV/ICS load the complete calendar on the  
server side anyway, so it doesn't matter speed-wise if we prefetch a  
day or a year. Of course it *does* matter bandwidth-wise.
But the other backends are much quicker loading day views than year  
views on the server-side, so prefetching more than what's actually  
requested would slow down everything.

Maybe we could pre-fetch the next (as in later) time range of the  
current view, once all calendars have finished loading. This way we  
don't slow down the original loading on backends that support  
time-range requests, but still speed up the most common navigation  
pattern: moving forward. Zooming out to a larger time range would  
still have to fill up the missing time slots, but at least that's a  
comprise.

> How is the client cache currently invalidated / how does it know a  
> new event was added by someone else?

Not at all. Kronolith on H6 has a refresh button though. We would need  
to track the calendar history, additionally to the event history, to  
allow synchronization of calendars to the ajax frontend.