[horde] Share performance problem

[Chuck Hagenbuch]

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
> impossible...

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  
bugs.horde.org?

Thanks,
-chuck