[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