gmane.mail.imap.dovecot

Timo Sirainen | 30 Nov 11:37

Zimbra benchmarking

Now that I have a working kvm setup, I thought I'd finally try how
Zimbra works. This is mainly some microbenchmarking, so it may not have
much to do with actual performance in real life.

Setup:

 - 1GB memory given to kvm (from host's 2GB)
 - Intel Core 2 6600 (kvm uses only one CPU)
 - CentOS 5
 - 15GB qcow2 image on XFS filesystem
 - Zimbra 5.0 RC2 RHEL5 x86_64
 - Dovecot latest hg, dbox format

Both Zimbra and Dovecot were tested running on the same kvm image. All
data could be cached in memory, so this didn't really test disk I/O.

Dovecot was run with fsync_disable=no. Running with =yes would have made
its performance even better.

Zimbra features/bugs
--------------------

Zimbra's SEARCH command doesn't support substring searching as IMAP
requires:

1 search text performance
* SEARCH 136 183 227 231 232 233 245
1 OK SEARCH completed
2 search text erformance
* SEARCH

(Continue reading)

headers

Farkas Levente | 30 Nov 11:55

Re: Zimbra benchmarking

hi,
nice test, but what would be also useful to compare cpu and memory
usage! with zimbra it's more important then anything else.
i'd like to see a comparison what kind of hardware (cpu and memory)
required for: 10, 100, 500, 1000, 2000, 5000 mailbox server. this's
where dovecot a big winner even for 10 mailbox.
but to be fair zimbra is much more than dovecot it's integrate many
things (ldap user and group management, samba domain controller, virus
scanner, outlook connector (!) not just for email but also for calendar
and address book, etc...) and to put together such a system with dovecot
it's more than hard and may be impossible.

Timo Sirainen wrote:
> Now that I have a working kvm setup, I thought I'd finally try how
> Zimbra works. This is mainly some microbenchmarking, so it may not have
> much to do with actual performance in real life.
> 
> Setup:
> 
>  - 1GB memory given to kvm (from host's 2GB)
>  - Intel Core 2 6600 (kvm uses only one CPU)
>  - CentOS 5
>  - 15GB qcow2 image on XFS filesystem
>  - Zimbra 5.0 RC2 RHEL5 x86_64
>  - Dovecot latest hg, dbox format
> 
> Both Zimbra and Dovecot were tested running on the same kvm image. All
> data could be cached in memory, so this didn't really test disk I/O.
> 
> Dovecot was run with fsync_disable=no. Running with =yes would have made

(Continue reading)

headers

"DINH =?iso-8859-1?b?VmnqdCBIb+Ai?= | 30 Nov 12:00

Re: Zimbra benchmarking

On Nov 30, 2007 11:38 AM, Timo Sirainen <tss <at> iki.fi> wrote:
> Zimbra is apparently building full text search indexes while appending,
> so this test doesn't mean much until I can test Dovecot's performance
> with Squat indexing.

Hello, in fact, I'm not that much convinced by full-text search index
server side.
We consider response time, server side full text search will include
client-server round-trip.
So that, for example, on etpanX, I do some local indexing on the imap
folders, so that when the user does a search, it's given in a fraction
of second even if the server is slow.
I think Mail.app on Mac OS X is doing the same.

--

-- 
DINH Viêt Hoà

headers

Timo Sirainen | 30 Nov 12:16

Re: Zimbra benchmarking

On Fri, 2007-11-30 at 12:00 +0100, DINH Viêt Hoà wrote:
> On Nov 30, 2007 11:38 AM, Timo Sirainen <tss <at> iki.fi> wrote:
> > Zimbra is apparently building full text search indexes while appending,
> > so this test doesn't mean much until I can test Dovecot's performance
> > with Squat indexing.
> 
> Hello, in fact, I'm not that much convinced by full-text search index
> server side.
> We consider response time, server side full text search will include
> client-server round-trip.
> So that, for example, on etpanX, I do some local indexing on the imap
> folders, so that when the user does a search, it's given in a fraction
> of second even if the server is slow.
> I think Mail.app on Mac OS X is doing the same.

Yes, and so do many other clients. But FTS indexes are useful for
webmails, mobile clients and other clients that don't have a local
cache.

Squat indexes are going to work so that the first time you do a TEXT or
BODY search the indexes are built for the mailbox. After that they most
likely are updated when saving new mails (although maybe only with
deliver, not with APPEND/COPY?). If user hasn't done any TEXT/BODY
searches for a month or so, the indexes finally get deleted. Or that's
my plan currently, those rules are easy to change.

headers

Adam McDougall | 30 Nov 17:11

Re: Zimbra benchmarking

On Fri, Nov 30, 2007 at 01:16:25PM +0200, Timo Sirainen wrote:

  On Fri, 2007-11-30 at 12:00 +0100, DINH Vi?t Ho? wrote:
  > On Nov 30, 2007 11:38 AM, Timo Sirainen <tss <at> iki.fi> wrote:
  > > Zimbra is apparently building full text search indexes while appending,
  > > so this test doesn't mean much until I can test Dovecot's performance
  > > with Squat indexing.
  > 
  > Hello, in fact, I'm not that much convinced by full-text search index
  > server side.
  > We consider response time, server side full text search will include
  > client-server round-trip.
  > So that, for example, on etpanX, I do some local indexing on the imap
  > folders, so that when the user does a search, it's given in a fraction
  > of second even if the server is slow.
  > I think Mail.app on Mac OS X is doing the same.

  Yes, and so do many other clients. But FTS indexes are useful for
  webmails, mobile clients and other clients that don't have a local
  cache.

  Squat indexes are going to work so that the first time you do a TEXT or
  BODY search the indexes are built for the mailbox. After that they most
  likely are updated when saving new mails (although maybe only with
  deliver, not with APPEND/COPY?). If user hasn't done any TEXT/BODY
  searches for a month or so, the indexes finally get deleted. Or that's
  my plan currently, those rules are easy to change.

I (and other users here) have some mail folder archives that go back several
years and a number of those folders won't change, I what I was thinking of

(Continue reading)

headers

"DINH =?iso-8859-1?b?VmnqdCBIb+Ai?= | 30 Nov 12:16

Re: Zimbra benchmarking

On Nov 30, 2007 12:00 PM, DINH Viêt Hoà <dinh.viet.hoa <at> free.fr> wrote:
> On Nov 30, 2007 11:38 AM, Timo Sirainen <tss <at> iki.fi> wrote:
> > Zimbra is apparently building full text search indexes while appending,
> > so this test doesn't mean much until I can test Dovecot's performance
> > with Squat indexing.
>
> Hello, in fact, I'm not that much convinced by full-text search index
> server side.
> We consider response time, server side full text search will include
> client-server round-trip.
> So that, for example, on etpanX, I do some local indexing on the imap
> folders, so that when the user does a search, it's given in a fraction
> of second even if the server is slow.
> I think Mail.app on Mac OS X is doing the same.

By the way, how does Dovecot index the messsages ? Does it do the following ?
- when doing the search, it will collect messages that were not indexed
- will index those messages
- and do the search on the updated index.

--

-- 
DINH Viêt Hoà

headers

sergey ivanov | 30 Nov 16:03

Re: Zimbra benchmarking

Hi,
for me zimbra swapped a lot on 1G of RAM even while serving mailboxes
for 3 users. But on 2G it runs such that I can't feel it's slower than
previously worked there dovecot.
-- 
    Sergey.

Timo Sirainen wrote:
> Now that I have a working kvm setup, I thought I'd finally try how
> Zimbra works. This is mainly some microbenchmarking, so it may not have
> much to do with actual performance in real life.
>
> Setup:
>
>  - 1GB memory given to kvm (from host's 2GB)
>  - Intel Core 2 6600 (kvm uses only one CPU)
>  - CentOS 5
>  - 15GB qcow2 image on XFS filesystem
>  - Zimbra 5.0 RC2 RHEL5 x86_64
>  - Dovecot latest hg, dbox format
>
> Both Zimbra and Dovecot were tested running on the same kvm image. All
> data could be cached in memory, so this didn't really test disk I/O.
>
> Dovecot was run with fsync_disable=no. Running with =yes would have made
> its performance even better.
>
> Zimbra features/bugs
> --------------------
>

(Continue reading)