OK, hardware specs:
Dual Xeon 2.8GHz SuperMicro with 4GB of ECC dual-channel DDR2-400 RAM and 3xU320 Fujitsu MAS 15,000 RPM hard disks with /, mail-store, and database storage all on different spindles.
SuperMicro 6014H-82 System Specs
OS: Red Hat Enterprise Linux ES release 4 (Nahant Update 4) fully patched up with all libraries spelled out in the Zimbra installation document properly installed. (X86_64 architecture) with SMP kernel 2.6.9-42.0.2.ELsmp
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.
Client browsers: Firefox 1.0.7, Firefox 18.104.22.168, and IE 6 (XP SP2 all patched up).
Browser config: session cookies allowed, direct (unproxied) connections to Zimbra, etc.
Output from zmstatus (with execution/wallclock time)
[zimbra@zimbramail ~]$ time zmcontrol status
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.)
# hdparm -t -T /dev/sdc
Timing cached reads: 2968 MB in 2.00 seconds = 1484.23 MB/sec
Timing buffered disk reads: 226 MB in 3.01 seconds = 74.99 MB/sec
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.