Results 1 to 10 of 10

Thread: memcached

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

    Default memcached

    Hi all,

    We have a lot of memcached (http://www.danga.com/memcached) servers around (to run our MediaWiki) and we really want to use them together with Zimbra. Is it possible? If yes, how? We can hack the code ourselves.

    -g.

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

    Default

    Since all the action/caching is in the server I guess this is where you would want to try to put it in. I'm not sure how much it would help though. We already partition the data similar to memcached. So we don't cache the same object in more than one place like other apps would do. A user's mailbox is on one DB and cached by it's local tomcat instance.

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

    Default

    Quote Originally Posted by KevinH
    Since all the action/caching is in the server I guess this is where you would want to try to put it in. I'm not sure how much it would help though. We already partition the data similar to memcached. So we don't cache the same object in more than one place like other apps would do. A user's mailbox is on one DB and cached by it's local tomcat instance.
    Yes, we want to implement memcached in the Zimbra server side. What we really want to cache is all the user information stored in LDAP. As I say in this thread http://www.zimbra.com/forums/showthr...?p=775#post775, we have bad performance problems with LDAP and in our current setup, we use nscd together with memcached to solve them. They help us pretty well, 50-70% LDAP connections are served directly by the local nscd/memcached server. We see no way to use nscd together with Zimbra so only memcached may help.

    Our plan is to make memcached become something like zimbra-cached, that means it's will be intergrated to the installer and users can choose whether to install it. If yes, they will be asked for some configuration information (how much RAM, the IP, the port...) and after that Zimbra will automatically be configured to use memcached.

    The Java Client API for memcached is available at http://www.whalin.com/memcached/. We havent used it before but it seems to be in active development. Its license is LGPL.

    What should we do? Please advise.

    -g

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

    Default

    Take a look at:

    /ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java

    You'll see the LDAP related caches we create. Currently we use a LRU cache.

  5. #5
    Join Date
    Sep 2005
    Posts
    95
    Rep Power
    10

    Default

    Ok thx Kevin, we will dive into the code and tell you the result later. Thx again.

    Best regards,

    -g

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

    Default

    Hey Kevin,

    As your suggestion, today I take a look at /ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java (many thx to the Eclipse team for the wonderful Java Browsing perspective ).

    After browsing a while, I think that memcached may help, especially for caching LDAP data. As far as I know, you havent got a centralized cache storage because each LRU cache is only available to its local zimbra-store. So there're probably objects stored the same in multiple zimbra-store servers. If we just have only one zimbra-store server, there's no benefit in using memcached but in a (very) large scale (as the one I'm going to deploy), memcached does help a lot.

    Do you have any plan to integrate memcached into zimbra? I think it wont take a lot of time. I can hack myself but I wonder whether you will integrate it to zimbra. I just dont want to use a heavy-patched Zimbra version (and busy patching when you guys release a new version with a lot of cool features!). Please advise.

    -g.

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

    Default

    Sorry, I'm a little bit wrong about your caching. I have just figured out that because each zimbra-store handles a different set of accounts so what are stored in LRU are totally different, regardless of LDAP or MySQL data.

    So the best caching stragedy is to use LRU for server-specific information such as those in dc=domain,dc=com (I mean user's accounts) and use memcached for global information such as those in cn=zimbra (domains, servers, cos...). IMHO, it doesnt worth to integrate memcached for just cn=zimbra data. It seems that the whole idea of using memcached together with Zimbra is broken .

    Sorry for wasting your time reading my meaningless words.

    -g
    Last edited by graffiti; 10-22-2005 at 12:50 PM.

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

    Default

    Your right we only have a local cache, but since user's are only assigned to one store there will not be any duplication. In general these cached objects are pretty long lived especially in the IMAP or MAPI(Outlook) case where clients connect very frequently to the store for a sync update.

    One place we may need to implement a cache on very large deployment would be on the postfix side of things. Since the postfix MTA pool is not tied to any particular domain or set of users each one will need to have access to the entire set of users. To solve this we can just have LDAP caches or we can implement a local cache on each postfix node. Many of us have came from companies that have deployed carrier/ISP scale mail systems. In this case we are talking terabytes of data and 10's of millions of LDAP entries and mailboxes. So we've seen and worked on some huge deployments.

    Maybe you can share with us your plans and the size of user base you plan to support.

    In any case with all contributions we will evaluate them for inclusion in a future release. In this case we'd need to do some heavy perf testing in our solution lab to see if the extra component (memcached) gives us enough benefit in terms of performance. I'm sure you'll do some of this testing yourself so you can get an idea of any benefit ahead of time.

  9. #9
    Join Date
    Sep 2005
    Posts
    95
    Rep Power
    10

    Default

    Kevin you are the ONE!

    I make a search on Google about Postfix and memcached, it returns a lot of projects and patchs. I will try to patch my zimbra-mta with memcached and tell you the result later.

    About my deployment, I'm planing to deploy Zimbra for 100.000 users with about 10.000 domains. To me, it's huge, pretty huge . The reason why I concern about LDAP is, as I have said, I have bad performance problem with LDAP and memcached has helped me a lot .

    In any case with all contributions we will evaluate them for inclusion in a future release. In this case we'd need to do some heavy perf testing in our solution lab to see if the extra component (memcached) gives us enough benefit in terms of performance. I'm sure you'll do some of this testing yourself so you can get an idea of any benefit ahead of time.
    To be honest, I dont know how to do perf testing with Zimbra. I just use vmstat/sar/iostat and users' feedback. What tools do you use? What should I do in order to test Zimbra perf?

    TIA,

    -g

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

    Default

    Quote Originally Posted by graffiti
    To be honest, I dont know how to do perf testing with Zimbra. I just use vmstat/sar/iostat and users' feedback. What tools do you use? What should I do in order to test Zimbra perf?
    Depends what interface you want to test. We have the zmlmtpinject tool that can test our LMTP interface. Or you could use the many IMAP/POP/SMTP tools available test there. Since your change would be to postfix seems you'd want to do some SMTP testing.

Posting Permissions

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