Forum .LRN Q&A: Response to Speed of dotLRN portal and applets

Collapse
Posted by Ben Adida on
Yes, the big issue with portal-based tools is that a lot of queries are being
performed. That explains your main page problem.

The calendar page time is unacceptable though, and requires optimization
(that's just one module). The file storage page is even more unacceptable.
Would be good to turn on developer support and see what queries are
causing this slowdown.

In general, for portals and OpenACS, I think it's time to investigate a data
caching system with domain-based invalidation. For example, cache data
related to calendar id N, and invalidate the cache for calendar id N only when
you add an event to that calendar. This isn't too difficult technically speaking,
but it does require some non-negligible amount of work.

This kind of caching approach could be applied to permission_p, although I
think the problem with permission_p is a bit deeper and needs to be
investigated a bit more in the direction that Don's been mentioning recently
(making sure the views are done correctly, simplifying the permission_p call
itself, etc..).