[Kolab-devel] Z-push optimization
Alain Abbas
alain.abbas at libertech.fr
Sun Oct 3 13:36:52 CEST 2010
Martin Konold a écrit :
> Am Freitag 01 Oktober 2010, 21:44:18 schrieb Jeroen van Meeuwen (Kolab
> Systems):
>
> Hi,
>
>
>> I understand this to result in great performance penalties, and hence I was
>> thinking the following scenario might make sense to pursue for the future;
>>
>> If Cyrus were enabled to keep it's mailboxes.db, annotations.db, seen.db,
>> and possibly even it's .index, .cache and .header in a true SQL database
>> backend, Kolab_Z-Push would be able to use Cyrus' SQL backend as if it
>> were cache.
>>
>> I've got several threads going on this approach already, so please let me
>> know what you think of using Cyrus' "live" as your "cache".
>>
>
> Sorry, but using a SQL db as backend for cyrus dbs is simply broken as hell.
> Please don't do that.
>
> It is plain wrong trying to gain performance for some use case by crippling
> the performance of the main use case.
>
> On the other hand if you know which kind of information Kolab_Z-Push needs you
> may obtain it much simpler and faster without the extra penality directly from
> the cyrus dbs.
>
In this case there are the problem of the remote access in case for
example Master/Slave or with Zpush on DMZ
> E.g. the access to Berkeley DB can be integrated savely into Kolab_Z-Push
> including proper locking if required.
>
> Going this route means get even faster data access for Kolab_Z-Push while not
> crippling the common case.
>
> Yours,
> -- martin
> P.S.: There are very valid reasons why cyrus, postfix etc. use non-sql dbs!
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
More information about the devel
mailing list