Re: Expected performance of importing mail?

[Matt Mencel <MR-Mencel@wiu.edu>]

We ended up using the mailutil package from the UW-IMAP stuff.  It had some feature we needed that imapsync did not have....and I think it was faster because it didn't have to go through an IMAP TCP session.

Matt

----- Original Message -----
From: "Robert M. Thompson" <ab5602@wayne.edu>
To: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
Sent: Friday, May 2, 2008 8:12:48 PM GMT -06:00 US/Canada Central
Subject: Re: Expected performance of importing mail?


We use Sun-sparc T2000's to support our Blackboard environment (Also Java-based) & my only complaint would be the CPU speed of those machines (current max: 1.2 Ghz).  They can handle an incredible amount of work, but they're just slow.  We've found that the same application responds much faster on Sun's X64 Opteron line of servers..  In addition, I've found that CPU speed has a lot to do with the snappiness of the Zimbra interface, providing ram is not limiting you.

BTW: I agree w/ ZFS, it's lightening fast and also saved us from a looming inode-limit issue too.

-Rob

-- 
Rob Thompson, Systems Analyst
Enterprise Applications
Computing & Information Technology
Wayne State University
313-577-5645


----- "Amos" <a.goo0h@gmail.com> wrote:

> On Fri, May 2, 2008 at 1:31 AM, Steve Hillman <hillman@sfu.ca> wrote:
> >  I'm a Solaris guy and am used to a much bigger bag of tricks when
> it comes to doing performance analysis. Unfortunately, a year of
> banging on Zimbra folks to support Solaris hasn't yielded the desired
> result, so we're stuck running on Linux, leaving me at a bit of a loss
> to dig deep into the server-side
> >
> 
> We're not using Zimbra (though hoping one day might), but have to
> admit I too would like to see Zimbra folks support Solaris. I would
> think in particular the "T" series servers would be a terrific fit
> for
> their Java application. We've also have had great results with ZFS,
> and think that would make a nice fit for their message storage. Oh
> well....
> 
> Amos