Re: nnimap slowness

[David Abrahams <dave@boost-consulting.com>]

Simon Josefsson <jas@extundo.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>>> It seems the IMAP SEARCH command is causing the delay (most of the
>>> nnimap related delay is in imap-search), suggesting that the server
>>> opens large messages when the SEARCH command is invoked.  This is
>>> unnecessary, since Gnus only searches for flags (unseen, seen, ticked,
>>> etc).  Perhaps you could forward this observation (after verifying it
>>> in the source) 
>>
>> The source of what?
>
> Of the server.  Assuming you have it, of course.
>
>>> to the IMAP server administrator/developers to have them improve
>>> searches for flags.
>>
>> We're using Communigate Pro, for what that's worth to you.
>
> I guess it doesn't come with source.  I recall the same problem was
> identified quite some time ago, but perhaps it was never reported
> upstream.  Asking the vendor to optimize the SEARCH commands for flags
> is probably the only practical solution then.

My sysadmin says:

    I'll ask about this in CommuniGate mailing list, but I think that
    implementation of IMAP SEARCH in CGPro is correct. This is a quote
    from press release:

    The POP and IMAP components of the CommuniGate Pro server not only
    support the latest Internet standards and all not-yet-standardized
    protocol extensions, but they also allow for simultaneous
    symmetric access to mailboxes. The high performance of IMAP
    built-in search engine results in huge benefits for individuals
    and organizations dealing with multi-thousand-message mailboxes.

    I think that problem is in our server - it's 650Mhz AMD with IDE
    hard drives.

But I'm suspicious that it's not the server since other mail clients
don't seem to have any particular problems with speed.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com