Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: Looks interesting, but....

  1. #1
    Join Date
    Sep 2005
    Posts
    47
    Rep Power
    10

    Default Looks interesting, but....

    After having used Cyrus for many, many years in a production environment with overall great success, I have to admit at being very anxious with the idea of dumping that (and migrating all the users) over to what is in all honesty is an untried implementation. We also make extensive use of shared ("public") folders and complex folder ACLs. I have a hard time seeing it being practical to dump that, even for what appears to be a rather nice client. (I'm at least impressed to see that apparently Zimbra supports Sieve. Though, would that only be one script per user?)

    I'm assuming the email messages are stored in MySQL, right? Do folks have any idea of the scalability for such an arrangement?

    What about the recovery of messages/folders? One thing I've always liked about Cyrus is that headers are cached, but the messages remain in single files. While this might be simplistic, it sure makes recovery of messages/folders immensely trivial. How does one go about recovering messages when they're in a db?

  2. #2
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    We actually only store meta data in the database. The messages are stored in MIME files in on the file system. Take a look at this doc for more details.

    http://www.zimbra.com/downloads/zimb...l_overview.pdf

    -kevin

  3. #3
    Join Date
    Sep 2005
    Posts
    47
    Rep Power
    10

    Default

    Quote Originally Posted by KevinH
    We actually only store meta data in the database. The messages are stored in MIME files in on the file system.
    Interesting.... I'll give it a read. Thanks.

  4. #4
    Join Date
    Sep 2005
    Posts
    4
    Rep Power
    10

    Default One File Per Message Has Been Tried

    Visual SourceSafe, the Microsoft source control tool, has used, still uses, one file per file version, which is equivalent to one file per message as Zimbra is using. With low total numbers it works OK; it does not scale. I see no reason to expect a different result here, which is unfortunate, because with the addition of a few other tools common to Notes or Groove, this is a dynamite product.

  5. #5
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    Visual SourceSafe, the Microsoft source control tool, has used, still uses, one file per file version, which is equivalent to one file per message as Zimbra is using. With low total numbers it works OK; it does not scale. I see no reason to expect a different result here, which is unfortunate, because with the addition of a few other tools common to Notes or Groove, this is a dynamite product.
    The filesystem access patterns of a source control system and a mime message store are quite different. Also Visual Source safe only runs on the MS Windows file system. In our case we use the Linux Ext3 file system which for our uses performs very well even with large mailboxes. The messages(files) are for the most part write once; read many. All the expensive searches are performed against the metadata in MySQL or the indexes of Lucene; both of which are designed for these types of queries.

    Regardless if/when you install our application and see things we've missed with regard to performance we'd be willing to review your test case. Our tests and trials have all yielded impressive performance but we are always looking for ways to improve.

  6. #6
    Join Date
    Sep 2005
    Posts
    4
    Rep Power
    10

    Default Ah, another color fish

    Using the metadata in a real database is a fish of another color, a color I hadn't caught. Thanks.

  7. #7
    Join Date
    Sep 2005
    Posts
    3
    Rep Power
    10

    Red face IMAP backend

    Ok, I'm impressed, but I'm also pretty happy with Cyrus IMAPd. (Also, regardless of the merits of any particular IMAP implementation, our mail store is so large that migrating it is something we would very much like to avoid.)

    So, I'm looking for an estimate on how difficult it would be to add a IMAP backend to Zimbra. The IMAP backend would probably have to cache a lot of data to keep things fast, but hopefully, it would be possible. Any thought?

  8. #8
    Join Date
    Sep 2005
    Posts
    3
    Rep Power
    10

    Talking

    Uh, ok that previous post, while somewhat on topic in this thread, would be more on topic in the Devel forums.

  9. #9
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    Quote Originally Posted by abo
    Ok, I'm impressed, but I'm also pretty happy with Cyrus IMAPd. (Also, regardless of the merits of any particular IMAP implementation, our mail store is so large that migrating it is something we would very much like to avoid.)

    So, I'm looking for an estimate on how difficult it would be to add a IMAP backend to Zimbra. The IMAP backend would probably have to cache a lot of data to keep things fast, but hopefully, it would be possible. Any thought?

    I think your next post meant you saw that we do have IMAP and POP support. But just to be sure. I'll say it

    We support IMAP/POP in additon to the AJAX web client.

  10. #10
    Join Date
    Sep 2005
    Posts
    3
    Rep Power
    10

    Default

    Quote Originally Posted by KevinH
    We support IMAP/POP in additon to the AJAX web client.
    Well, actually, what I'm after is an IMAP client inside Zimbra, so that I can keep the mail on the existing IMAP server but still use the Zimbra AJAX web client.

    So, why not move the mail into Zimbra? This is going to sound like I'm complaining, but I assure you I'm not. I'm just trying to explain. Perhaps if we like Zimbra enough we could dedicate resources to developing the extensions we need, in the spirit of Open Source.

    With many thousands of users and houndreds of gigabytes of mail, moving would be a big deal. First, there would need to be lots of evaluation and proving that it all works and is the right solution for us. Then, moving it all a once would probably be impossible, the downtime while the store is in transit would be too long. So we'd have to move it one mailbox at a time, which means users would at the right moment need to change their settings to use the new server since the new server couldn't use the hostname of the old server. Possibly, some kind of proxy could be put in place to hide the fact that there are multiple server, but it still a big project.

    Also, does it have all the features we need from an IMAP server? Like scalability: Cyrus has Murder, a proxy that allow the mail store to be split up into several machines. That's something we're considering using. Another thing we need is Kerberos support. I think I saw something about Zimbra using Cyrus SASL. In that case perhaps single-sign-on using Kerberos already works.

    So, keeping the mail on our trusty old Cyrus IMAPd, but using Zimbra as a web mail client and as a collab suite would probably work very well for us. It'd give us a what we need while at the same time being simple to implement (after the code has been written that is) and require no changes to the existing infrastructure.

Similar Threads

  1. Disable admin from viewing user mails
    By scalper in forum Administrators
    Replies: 4
    Last Post: 07-06-2007, 06:25 AM
  2. Include contacts from a file
    By Oswald-Kolle in forum Developers
    Replies: 1
    Last Post: 03-01-2007, 10:32 AM
  3. Security Bug in Zimbra?
    By generic31 in forum Administrators
    Replies: 19
    Last Post: 02-05-2007, 09:46 PM
  4. Changing the port Zimbra uses
    By crp in forum Administrators
    Replies: 9
    Last Post: 11-05-2006, 10:52 AM
  5. Very Interesting. What about Revenues ?
    By managedcode in forum Users
    Replies: 3
    Last Post: 10-07-2005, 08:09 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •