Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Performance issues on fresh install onto a pretty good machine.

  1. #1
    MalcolmB is offline New Member
    Join Date
    Sep 2006
    Posts
    4
    Rep Power
    8

    Default Performance issues on fresh install onto a pretty good machine.

    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 1.5.0.7, 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
    Host zimbramail.XXXXXX.com
    antispam Running
    antivirus Running
    ldap Running
    logger Running
    mailbox Running
    mta Running
    spell Running

    real 0m3.060s
    user 0m2.853s
    sys 0m0.643s

    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.)

    To wit:

    # hdparm -t -T /dev/sdc

    /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.

  2. #2
    KevinH's Avatar
    KevinH is offline Expert Member
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    18

    Default

    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.

  3. #3
    MalcolmB is offline New Member
    Join Date
    Sep 2006
    Posts
    4
    Rep Power
    8

    Default

    Quote Originally Posted by KevinH
    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.

  4. #4
    Klug's Avatar
    Klug is offline Moderator
    Join Date
    Mar 2006
    Location
    Beaucaire, France
    Posts
    2,316
    Rep Power
    13

    Default

    Quote Originally Posted by MalcolmB
    So it's normal for a simple "zmcontrol" command to require 3+ seconds?
    Here are my own results on a quad-Xeon 700Mhz server (2MB cache each, 4GB RAM, 4x72GB RAID 5 volume running CentOS) :
    real 0m7.131s
    user 0m4.836s
    sys 0m1.562s

    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.

    Do you have the same issues on the little Duron and the Pentium M ?
    Last edited by Klug; 09-25-2006 at 01:39 AM.

  5. #5
    dijichi2 is offline OpenSource Builder & Moderator
    Join Date
    Oct 2005
    Posts
    1,176
    Rep Power
    11

    Default

    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.

  6. #6
    KevinH's Avatar
    KevinH is offline Expert Member
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    18

    Default

    Quote Originally Posted by MalcolmB
    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.

  7. #7
    MalcolmB is offline New Member
    Join Date
    Sep 2006
    Posts
    4
    Rep Power
    8

    Default

    Quote Originally Posted by dijichi2 View Post
    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?

  8. #8
    Klug's Avatar
    Klug is offline Moderator
    Join Date
    Mar 2006
    Location
    Beaucaire, France
    Posts
    2,316
    Rep Power
    13

    Default

    MalcolmB, we're many (at least two) to think your issue resides on the client side.

    What was the computer used by the "test account" ?

  9. #9
    phoenix is online now Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,470
    Rep Power
    56

    Default

    Do the clients also use Windows? if they do they should us FF as it faster than IE6. You don't say whether you've upgraded to the most recent release of Zimbra, there have been performance improvements since you originally posted your 'problem'.
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

  10. #10
    dijichi2 is offline OpenSource Builder & Moderator
    Join Date
    Oct 2005
    Posts
    1,176
    Rep Power
    11

    Default

    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?
    i mean typically this slow response is consistent even when you ramp the usage of the server up to many users and very large mailboxes. there are a few steps you can take such as disabling any component or zimlets you don't use.

    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.
    logging in is not a trivial thing with ajax apps. someone else on the forum here did a trace of how much code is downloaded to the client logging in and its huge, well over a meg, and it typically hangs the client while logging and executing all that javascript. however, once logged in most things are very responsive, and doing things like realtime contact searches, mailbox searches etc even of very large mailboxes are fast. it does require education of the users and them to get used to it. some do, love it, and never return to native clients or traditional webmail clients, others hate it and go straight back. as with every other mail server you are of course open to still use whatever client they're used to, including full support for imail and outlook with the connectors. i have in the past used squirremail and horde to provide a familiar interface, most people on my systems use thunderbird.

    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?
    i've found the backend makes very little difference, my main system runs on a P3-800Mhz and is pretty much as fast as newer multi-Ghz large ram systems. The client cpu makes a massive difference.

Page 1 of 2 12 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 3
    Last Post: 11-03-2007, 10:55 PM
  2. fresh install (both OS and Zimbra) but zimbra-spell fails
    By xtremetoonz in forum Installation
    Replies: 14
    Last Post: 09-09-2007, 12:34 AM
  3. A couple of install issues -- MX and domain
    By Storm16 in forum Installation
    Replies: 2
    Last Post: 10-31-2006, 11:31 AM
  4. Going Crazy (Fresh Install Problems)
    By hirnschmalz in forum Installation
    Replies: 2
    Last Post: 09-16-2006, 03:55 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
  •