[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Zimbra v6 - slow autocomplete
The biggest reason we went to it was the issue of deleting more than 25 messages and not having them be removed from the listing unless you refreshed your browser.
I iPhone bug was a fairly important one for us to but less likely to happen compared to the first issue.
Doug
----- Original Message -----
> From: "Tony Publiski" <tonster@tonster.com>
> To: "Fred Seaton" <F-Seaton@wiu.edu>
> Cc: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> Sent: Wednesday, October 20, 2010 5:44:43 PM
> Subject: Re: Zimbra v6 - slow autocomplete
> https://support.zimbra.com/ZCS608P3 explains the patch and what it
> includes.
>
> Tony
>
> ----- Original Message -----
> From: "Fred Seaton" <F-Seaton@wiu.edu>
> To: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> Sent: Wednesday, October 20, 2010 5:28:51 PM
> Subject: Re: Zimbra v6 - slow autocomplete
>
>
> What's the Patch 3 on 6.0.8? I haven't seen any announcement on such a
> patch.
>
> Fred
>
> ----- Original Message -----
> From: "Doug Curtis" <doug.curtis@oit.gatech.edu>
> To: "Steve Hillman" <hillman@sfu.ca>
> Cc: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> Sent: Wednesday, October 20, 2010 4:01:24 PM
> Subject: Re: Zimbra v6 - slow autocomplete
>
> We upgraded last weekend to 6.0.8P3 and are seeing this problem too.
> We voted for the bug also but we aren't holding our breath.
>
> So far 6.0 is working pretty well, except for autocomplete. Overall,
> users seem much happier with Zimbra 6.
>
> Thanks,
>
> Doug
>
> ----- Original Message -----
> > From: "Steve Hillman" <hillman@sfu.ca>
> > To: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> > Sent: Friday, October 15, 2010 5:59:12 PM
> > Subject: Zimbra v6 - slow autocomplete
> > Since there has been some discussion on this list about what to
> > expect
> > regarding performance when upgrading to Zimbra 6, I thought I'd
> > share
> > a story about an issue we encountered. The executive summary is that
> > autocomplete speed is adversely affected when a user has messages
> > waiting to be indexed. The BugID to work around this is here
> > https://bugzilla.zimbra.com/show_bug.cgi?id=46963 but has been
> > targeted for Zimbra 7, which for us is at least a year away. Read on
> > for the technical explanation
> >
> > In Zimbra 5, contacts were loaded into the browser at login time.
> > When
> > an autocomplete operation was performed, the search was done by
> > javascript in the browser using the loaded contacts. If less than 20
> > matches were found, and if the GAL was enabled, a SOAP call was made
> > to the server to do Autocomplete using the GAL. This resulted in the
> > initial autocomplete being very fast, with the GAL results (if any)
> > loading afterward - typically a second later.
> >
> > In Zimbra 6, autocomplete has been completely redesigned. Now, the
> > contacts aren't loaded into the browser. *All* autocomplete
> > operations
> > do a SOAP call to the server. The server searches your contacts for
> > matches and, if appropriate and configured, also queries the GAL.
> > But
> > there's a problem: From my trace-level debugging, it appears that
> > the
> > autocomplete mechanism uses the Lucene Index files to do a quick
> > search (the same ones that index messages and most other blobs), but
> > those index files can potentially be out of date if messages have
> > arrived recently and you have batch indexing enabled (recommended
> > for
> > large sites and I think the default in Zimbra 6). Right now, if the
> > index files are detected as being out of date, an indexing operation
> > is kicked off and any messages that haven't yet been indexed are
> > done
> > on the spot. The problem is, this all happens while the user is
> > waiting for the autocomplete operation to complete. Depending on how
> > many messages there are, how busy the server is, and how busy the
> > index disks are, this indexing can take anywhere from sub-seconds to
> > 20-30 seconds. All while the user waits.
> >
> > This is most noticeable with power users who get a lot of mail -- I
> > see it all the time. Light-duty users may never notice it.
> >
> > A workaround could be to add code on the server to the autocomplete
> > that simply skips the reindex operation. Since the vast majority of
> > the time, it's only message blobs waiting to be indexed, this should
> > very rarely affect the autocomplete results. Unfortunately, the fix
> > for this issue has been pushed to Zimbra 7. For us, that means a
> > year
> > of living with the annoying delays.
> >
> > If you've already upgraded to Zimbra 6, I'm curious whether you've
> > noticed these delays. If you have screaming fast index volumes or
> > lightly loaded mailbox servers, perhaps you don't notice it. If you
> > do
> > notice it, feel free to vote on the bug and add a comment that it's
> > a
> > QA issue for you. It would be great to get a hotfix into 6.0.9 if
> > possible
> >
> > --
> > Steve Hillman IT Architect
> > hillman@sfu.ca IT Infrastructure
> > 778-782-3960 Simon Fraser University
>
> --
> Doug Curtis
> doug.curtis@oit.gatech.edu
> Georgia Tech OIT/A&I
> 404.385.0390
--
Doug Curtis
doug.curtis@oit.gatech.edu
Georgia Tech OIT/A&I
404.385.0390