I am looking at Davical performance, since my own servers are beginning
to struggle under the load of thousands of calendars and calendar items.
I notice that the standard Davical install script does not apply any
database indexes, over and above those required for key constraints.
Does anyone have any experience in this area, e.g. recommendations for
suitable indexes to apply to improve query and update performance? I am
thinking that the caldav_data and calendar_item tables in particular are
suitable for optimisation with some carefully-chosen indexes.
I also notice that there are two areas of the Davical code which incur a
substantial performance hit when a single user has many calendars:
1. When retrieving a principal, the "schedule-default-calendar-URL" is
always populated. This runs a potentially expensive SQL query (actually
expensive on my server!) to retrieve all calendars for the given user,
then searches through them all (in PHP) looking for one called "home";
if not found, it uses the first calendar. I think the query needs to be
improved here so that the database does more of the work. Even better,
perhaps the home calendar URL ought to be stored in the database as a
separate field, e.g. on the "principal" table.
2. Also when retrieving a principal, a "calendar_free_busy_set" property
is populated. Again this is expensive, with a complicated SQL query over
the collection table. In this case, it appears that
calendar_free_busy_set is not in the extant CalDAV RFC - I think it
appeared in a draft but was then removed. So should Davical be
populating it at all?
I am considering making code changes to improve these areas. Would the
community like these committed back to the repository? What about
(performance-related) database indexes - should these be part of the
standard build of Davical?
Mark Davies
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
to struggle under the load of thousands of calendars and calendar items.
I notice that the standard Davical install script does not apply any
database indexes, over and above those required for key constraints.
Does anyone have any experience in this area, e.g. recommendations for
suitable indexes to apply to improve query and update performance? I am
thinking that the caldav_data and calendar_item tables in particular are
suitable for optimisation with some carefully-chosen indexes.
I also notice that there are two areas of the Davical code which incur a
substantial performance hit when a single user has many calendars:
1. When retrieving a principal, the "schedule-default-calendar-URL" is
always populated. This runs a potentially expensive SQL query (actually
expensive on my server!) to retrieve all calendars for the given user,
then searches through them all (in PHP) looking for one called "home";
if not found, it uses the first calendar. I think the query needs to be
improved here so that the database does more of the work. Even better,
perhaps the home calendar URL ought to be stored in the database as a
separate field, e.g. on the "principal" table.
2. Also when retrieving a principal, a "calendar_free_busy_set" property
is populated. Again this is expensive, with a complicated SQL query over
the collection table. In this case, it appears that
calendar_free_busy_set is not in the extant CalDAV RFC - I think it
appeared in a draft but was then removed. So should Davical be
populating it at all?
I am considering making code changes to improve these areas. Would the
community like these committed back to the repository? What about
(performance-related) database indexes - should these be part of the
standard build of Davical?
Mark Davies
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
