From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/51143 Path: main.gmane.org!not-for-mail From: David Abrahams Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap slowness Date: Mon, 31 Mar 2003 17:31:16 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1049149941 26875 80.91.224.249 (31 Mar 2003 22:32:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 31 Mar 2003 22:32:21 +0000 (UTC) Original-X-From: owner-ding@hpc.uh.edu Tue Apr 01 00:32:19 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1907pC-0006zF-00 for ; Tue, 01 Apr 2003 00:32:18 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1907ok-0003wo-00; Mon, 31 Mar 2003 16:31:50 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 31 Mar 2003 16:32:53 -0600 (CST) Original-Received: from stlport.com (stlport.com [64.39.31.56]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id QAA14512 for ; Mon, 31 Mar 2003 16:32:41 -0600 (CST) Original-Received: from [146.115.123.42] (account dave HELO PENGUIN.boost-consulting.com) by stlport.com (CommuniGate Pro SMTP 3.5.9) with ESMTP id 217340; Mon, 31 Mar 2003 14:31:33 -0800 Original-To: ding@hpc.uh.edu In-Reply-To: (Simon Josefsson's message of "Mon, 31 Mar 2003 14:30:24 +0200") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (i386-msvc-nt5.1.2600) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:51143 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:51143 Simon Josefsson writes: > David Abrahams 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