Cache the events from the 'Upcoming Events' portlet.

[frapell]

No description provided.

[mister-roboto]

@frapell thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[frapell]

@thet @petschki What do you think of this? does it make sense? As I mention in the ticket, in my case it does make a huge performance improvement, but not entirely sure if it makes sense to include it in the product...

[petschki]

@jenkins-plone-org please run jobs

[thet]

Hi, caching the results makes perfect sense. but the cache key calculation looks quite expensive by itself? Isn't there a way for a simpler cachekey?

[frapell]

@petschki @thet Thanks for looking at this. Unfortunately, since this portlet is expected to show the upcoming events, the cached results should be void when there's a new event to show, and I cannot come up with a faster query to do this... Now, I don't think it is really a big issue, since it is simply a catalog call. I created a Plone site from scratch with 4000 events in the future, and an "Upcoming events" portlet at the root. here are some profiling details:

While using this branch, I have profiled a first call (When the instance has just come up and you are issuing the very first request), and then a new profile for a second call without restarting the instance:

• With the first call, where both _render_events_cachekey and events are called, I can see that the former takes 30ms while the latter 900ms. Total render time: 1.84s
• With the second call the _render_events_cachekey takes 10ms, and the events of course is not even called. Total render time: 920ms

I repeated this using the master branch:

• With the first call, events is called, taking 850ms. Total render time: 2.22s
• With the second call the events is called again, taking 400ms. Total render time: 1.36s
  profiles.zip

I am totally open to a better cachekey function, in case you have one.

Attaching the profiles here, you can open them in https://www.speedscope.app/

profiles.zip

[thet]

@frapell @petschki I have made a possible improvement for the cachekey. It queries only the latest modified event for all upcoming events and uses that to calculate the cachekey. It is the last commit on this branch and can easily be reverted.
However, I think I have made a regression here. Your version @frapell queries only the next 5 (or whatever is configured) upcoming events and calculates the cachekey from that. I query the latest modified of any upcoming events to calculate the cachekey. Now if a site has a very high frequency of events added the portlet would always be re-rendered even if the events are far beyond the set of events which are displayed in the portlet.

What is your opinion on this?

[petschki]

@thet I would not update the cachekey on every changed event. We're running an event portal with lots of changes and there wouldn't be a real benefit from this caching strategy. @frapell 's solution with the configured events would work better for me.

[thet]

I‌ thought so. Will revert to previous state and merge then.

[thet]

I‌ reverted to the previous logic with two changes:

• The query is limited to only upcoming events. That's also what the portlet events method does.
• The query searches for IEvent objects using the object_provides index. The rest of plone.app.event does the same and that allows for the initial plone.app.event design, where you can enable the "IBasicEvent" behavior on any object and make that an event that way.

@petschki @frapell please check again

[petschki]

LGTM!

[thet]

@jenkins-plone-org please run jobs

[thet]

@frapell that's now targeting Plone 6. If you need that for Plone 5 please backport it and I or petschki or someone else will approve it more quickly ...

[frapell]

@petschki @thet Thank you guys! I don't think I need it on a P5, but will submit a PR in case I do!