[Dovecot] Zimbra benchmarking

[Adam McDougall]

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
doing was do a full text search over ALL of the mail I can possibly access,
so I will be all set for future fast searches, which might be of interest
only once a year.  I was thinking after we get dovecot into full production
for at least half or a whole year, evaluating the space used by indexes of 
any type and make a site specific purge script if desired.  It sounds like
the indexes, if not automatically deleted, will be worth the more or less
permanent disk space for us.  Sounds like it would be useful as a configurable
option.