Some time ago I was watching Zimbra webinar on issue "Why ZCS is better than Gmail". While I was expecting more focus on interface benefits and ZCS offered services, more or less, Zimbra CS turned out to be very good solution (alternative) as a local deployment, e.g. leaving out of game aka ZCS service providers. At least that was my understanding of this positioning, as the benefits were leaning more towards code, software and deployment ease and control. Although, from the other side, ZCS, practically, is the only packaged solution capable of multidomains and service providers oriented solutions, including stable and very usable web interface, including different mobile/offline solutions. Honestly, our customers say, that they like ZCS web client better, than Gmail. And for this I think, we have to thankyou Microsoft Why? Our customers say, that Gmail interface is something you have to learn, but in ZCS - everything looks very familiar to MS Outlook .

Nevertheless, this was not my main point of discussion. My question or discussion offer is connected to scaling ZCS as a provider regionally. I understand, that there are very many other connected issues for that, like international or customer internet access speeds, as well as their computer power and ISP offered speeds, but experimenting and testing in different manner, I came to issue, that I have to solve ZCS Web client operational speed. Sometimes our customers complain, that ZCS web client is very slow, and in this case, they compare it to Gmail interface speed, which is much better, taking in mind related networking issues, etc. Due to this, I was testing zimbra on RedHat Enterprise Cloud, increasing machines to beefy values, without any significant impact at the customer end. And I was starting to think about reginal distribution. I would be glad to have discussion with people of some experience in this field.

My initial thoughts of solution findings come down to the following possibilities (not in specific order for importance/effectivity):

1. Building whole ZCS stack closer to actual customers (e.g. opening accounts in local datacenter companies, and servicing such customers from there).
2. Moving ZCS Web client static files to CDNs (by implementation of hand made rewrite rules for such files).
3. Creating distributed network of Zimbra Proxy servers (leaving main mailboxes in current datacenter, due to lower service and management costs).
4. Creating distributed newtork of 3-rd party Proxy servers with cashing, tuned to authenticated sessions, etc.


SOME ASSUMPTIONS ON VARIATIONS ABOVE

Overall, speed issue is connected with time, from entering login info, till loading full web application. Afterwards, operations are understandable, if, for example, user is operating with large attachments, or so. But feeling of first screen being slow, lays down this speed increasion issue.


ZCS CLOSER TO CUSTOMERS

This solution would be double, tripple, etc. in administration tasks, as well it'l increase operational costs. But main benefit will be only for customers working locally only (regarding specific region of deployment). Mainly our issues with ZCS speed raised with customers working in one company in different regions, and travelling arround, where in such case this increase of opeeration speed in a region, will give only small benefit, comparing to possible additional operational costs.


ZCS STATIC FILES TO CDN

Although, ZCS web client interface is only arround 550-600KB in weight, Yslow testing raises 2 issues - CDN usage for static files and Decreasing of number of DOM elements. While the last task would be impossible, I think, that rewriting URLs with some kind of proxy implementation, could be done, to move these static graphic and script files to CDN, for distribution. Although, can not comment on real speed increasing benefits. May be somebody can comment on this?


ZCS PROXY DISTRIBUTION NETWORK

While ZCS has its own solution for proxy, it is probably wise to use it for this aim, thus potentially leaving data transfers between regional proxy and main mailbox in central datacenter. And again, what could be expected increases or benefits in terms of web client speed? Probably exploring ZCS Proxy Memcache settings, there could be some gains of performance too, if tuning can help.


3-RD PARTY PROXY NETWORK

Referencing this way of solution, it is known, that memcache is usually used for non-authenticated sessions - e.g. the same static files or publicly available data. But there are solutions for implementations of authenticated user caching, which probably could be a solution in ZCS web client case, to gain more speed, depending on the region, a user is accessing his/her account via web client.

Or may be your practice shows, that web interface speeds are not so related to internet networking, but more relay on ZCS inside network and performance tuning between main servers - proxy, MTAs, Mailbox and LDAP (all run separately). Some times I have a feeling, that LDAP server is the narrowest link. While LDAP requests are relatively small, it somehow gives a feeling, that this timeout is connected with authentication process. And afterwards it is successfull, it starts to load web application. But increasing of technical parameters for LDAP, didn't give any increase in this process. I was testing this on small multiserver installation - arround 60 accounts, including IMAPs, POPs and web access. Currently LDAP runs on 2GB RAM, but I was increasing up to 8GB, with no feelable difference. Although, locally, where datacenter is located, Webclient is rather quick, even on middlesized DSL connections.

Can we compile some recomendations on these issues?