Zimbra Network Edition with trial licence key (downloaded just a day ago - the most recent version, I'm assuming here).

Firewall Settings: all localhost connections permitted, and various service protocols permitted on the local ethernet segment. I've logged all REJECTing firewall rulesets and monitored the server during startup as well as during usage for any connection attempts issued to or generated by Zimbra to ensure network connectivity is fine.

LAN Setup: local ethernet-available caching DNS setup, working correctly. Both the FQDN and reverse IP# DNS records are properly defined, and the MX record for the Zimbra server is also correct.

I've done TCP and UDP packet tests up to the limits of hardware (almost 12MBytes/second) between the Zimbra server and five different endpoints. The ethernet cabling and switch ports are fine.

Is this a "Java thing", i.e., everything being so slow? When I first started up the server after installing everything, I thought there was a problem initially.

Performance issues: (all are "hot" figures - primed by logging in and logging out three times)

1) Initial pageview time of the login screen: 6.8 seconds

2) Time from clicking the "Login" button to actual "home" screen area repaint: 7.3 seconds

3) Time from clicking LOGOUT to Login screen: 5.0 seconds.

Is this normal? The server is all freshly formatted, and doesn't even have an X11 gdm running. It's text mode with a barebones set of services (sshd and whatever Zimbra installs and uses). These Fujitsu U320 drives are nearly the fastest you can buy. (The machine is a cold standby database server.)

If this is indeed the expected performance for Zimbra Network Edition, then please tell me now so I can put an end to my company's evaluation because this is not the level of performance management expects out of a groupware application.

If this is way off base, I would welcome suggestions and ways to investigate and/or fix this performance. I have configured only three users on it, and during my testing, I was the only user.

uptime reports near 0.0 load average before my testing starts, and ps aux confirms nothing is consuming CPU time. While I examine "top" during network transactions, "java" processes are using 70+ % CPU for the duration of the transaction.

My PHP4-based webmail product on a remote LAN (over https) is 6-10x faster on P4A-2GHz/1.5GB RAM hardware, and it almost always has at least 10 simultaneous users on it over the weekend.

Your 1/2/3 times do seem a little longer than normal for such powerful box. Are you using http or https? Do the browser's have caching disabled? We do purposely take a perf trade off and pre-load folders/contacts etc to make data access quicker once your logged in, but ~15sec from first hit to inbox seems a little long. Any data in the account? mail? contacts? folders? etc...

I'm sure you can see comparing start-up time of a html/php page based app with a single page AJAX app is apples to oranges. A better comparison would be the startup time of Evolution/Outlook/Thunderbird (ie loading an application and some pre-caching).

How does the app work and perform once you've logged in and started to use it?

Looking for new beta users -> Co-Founder of Acompli. Previously worked at Zimbra (and Yahoo! & VMware) since 2005.

Your 1/2/3 times do seem a little longer than normal for such powerful box.

I'm glad you agree.

Are you using http or https?

http only.

Do the browser's have caching disabled?

Nope, pretty stock out of the box - though browser caches are limited to 20MB on the clients. I even override the proxy so the browsers go directly to the zimbra server.

Any data in the account? mail?

No, and none.

contacts?

None.

folders?

None. It's a fresh install. I've not migrated ANYTHING over yet.

I'm sure you can see comparing start-up time of a html/php page based app with a single page AJAX app is apples to oranges.

Sure, though at the end of the day it needs to provide a responsive application to my users.

The client systems are alot less manly - only 1.5GHz Athlon XPs, 1.8GHz Duron (Applegate core), and maybe a 1.6GHz Pentium-M. Minimum client-side config is only 512MB of RAM (Windows 2000), but two have 1GB (Windows XP). Does this AJAX stuff punish the client-side users who lack CPUs of the gods?

A better comparison would be the startup time of Thunderbird (ie loading an application and some pre-caching).

Thunderbird's very fast on the clients which have it installed.

How does the app work and perform once you've logged in and started to use it?

It's soupy. If I were to make a stab at characterising the performance, it feels "high latency" but not necessarily "low bandwidth" in the sense that nothing ever "snaps" in response to user actions, but the size of attachments or what have you don't seem to affect response times. Though this could be because that contribution to the overall response time of the "variable" costs are so small by comparison. I can make a small movie showing the login process and basic actions unfold. Maybe this is "normal" performance, and I'm just impatient.

So it's normal for a simple "zmcontrol" command to require 3+ seconds? I can see there is indeed a 64-bit JVM installed and being used (the 32-bit one used by another subsystem refers to "java32").

Is it your feeling that it's something lacking on the clients' or the server's end at this point? I'm happy to dump logs, tables, config files, but to be honest I've not changed much at all from the base install. Would enabling hyper-threading help? (Providing more than two threads of concurrency.) The kernel uses HZ=1000, so any select() based I/Os will hit the scheduling edges a bit faster than at HZ=100.

I've never found java code to be thrilling in performance, but this disappointed me even with that pre-qualification.

It's way slower than your results but, OTOH, the WebUI is twice faster as yours and does not feel soupy at all (while being connected through ADSL to the server) when tested from my Vaio laptop (Pentium M 1.5GHz, 1GB RAM, awfull 32MB Radeon Mobility running XP and Firefox 1.5.0.7)...

This would led me to think the problem might be on the client side.
I've done a few fasts tests on Athlon 2800XP+ clients (quite nice CPU, aren't they?) under XP and Firefox 1.5.0.7 with 512MB (only 384MB free as 128MB is used for motherboard integrated graphical card)...
Results are quite bad : loading the WebUI brings up 100% CPU (javascript engine or graphical card, I don't know) on login page loading or, once loaded, on first page displaying.

as pointed out, your startup performance figures have little to do with the performance of the application and you cannot compare them to a traditional webmail - which effectively reloads the entire application for every operation. in practice most of my clients have learnt to live with the slow startup because they only do it once a day. there tends to be a small latency with each operation inside the application - this is the client doing soap requests and processing the answers - but once you get used to it, it's consistent and scales well as you've noticed with large operations.

zmcontrol and most of the other cli utils are very very slow, i'm not sure why and it would be nice if they were sped up at some point.

bonnie is a more useful benchmark than hdparm, which is a crude contiguous timing.

If this is indeed the expected performance for Zimbra Network Edition, then please tell me now so I can put an end to my company's evaluation because this is not the level of performance management expects out of a groupware application.

i understand your reaction, i had the same reaction when I first started using zimbra, especially coming from lightening fast cyrus/horde system, however once you appreciate the scalability, quality of engineering and the entirely different technical and workflow ethos behind zimbra it starts to make a lot more sense. i am forced to use a outlook/exchange/windows system at my day job for email and it's excruciatingly slow and painful to use.

i understand your reaction, i had the same reaction when I first started using zimbra, especially coming from lightening fast cyrus/horde system, however once you appreciate the scalability

I'm not sure I understand what you mean by "scalable" when the performance is so lacking for an idealised/lightweight user testing scenario. Are you saying the low performance is something that "gets better" because you become more accustomed to it?

Trust me, my users are not so forgiving. I handed out some test accounts to the more adventurous users and they all to a man thought the server was hung after 5 seconds and clicked refresh in their browsers. (They're accustomed to sub-second response times for trivial things like logging in/refreshing the inbox, even on the webmail app.) Fine, that's a typical LUSER response, but it's indicative of what I'll be dealing with.

i am forced to use a outlook/exchange/windows system at my day job for email and it's excruciatingly slow and painful to use.

I'm happy to say I've never had to support Exchange in any flavour.

I'm open to ideas, but I've yet to resolve this performance pathology. Is this to be considered the "baseline", or do I need the new Quad Core 1066MHz 8MB L2 cache FSB CPU with 32GB of DDR2-1066 RAM and a large rack of EMC drives to make this respond the way my existing servers with relatively ancient P4 2.0Ghz (Northwood) CPUs, 2GB of (PC133 no less) RAM, and SCSI-160s (not even RAIDed) do?

Is it your feeling that it's something lacking on the clients' or the server's end at this point?

I'd guess client. One check would be to run task mgr or perfmon on the client and see what the CPU/mem usage is. Also pick out one of your better client machines and try the test with Firefox 1.5 to see if it performs better. AJAX apps in general do trade off some CPU cycles to the client so you should see some activity but if it's pinned at 100% usage for the whole time that may say your clients are under powered.

Looking for new beta users -> Co-Founder of Acompli. Previously worked at Zimbra (and Yahoo! & VMware) since 2005.