[horde] Share performance problem
chuck at horde.org
Sat Sep 6 03:24:00 UTC 2008
Quoting Janne Peltonen <janne.peltonen at helsinki.fi>:
> At the end, we had to change the _getShareDescription method in the
> Share sql backend to only return a simplistic search in the share table
> that only returns the shares that are owner by the user. That way, we
> could get rid of the bitwise and operations (which, according to the
> message linked above, are the real culprit). And our installation began
> to fly... (the simpler version of the query took less than a second when
> the mysql server was on its knees, and only a couple milliseconds when
> it had gotten rid of the monstrous queries).
> So, two questions:
> 1) Does anyone have any ideas on how to optimize the kind of SQL queries
> mentioned in the message? We'd like to enable sharing of calendars and
> address books one day again, but with these loads it appears
Sorry for my delay in replying to this. The only obvious answer is to
use a different way of storing permissions in the database that
doesn't rely on bitwise comparisons. Unfortunately that's a long view
answer. I don't have a short view answer right now, though I'm
certainly open to ideas.
> 2) Why is it that even when sharing, even of addressbooks, is disabled
> (there is an empty string as the share backend in conf.php), such
> expensive queries are still generated?
If the share backend is completely disabled, it _should_ be impossible
for a share_sql object to be instantiated. Did you log in/out after
making this change? Config settings are cached in the session, so it
would persist until a logout.
If that's not it, it sounds like a bug; would you create a ticket on
More information about the horde