why are you want to need a detail? tell me?

I am finding that dragging messages over to folders (server is Mercury 4.74 and client is Thunderbird 10.0.2), in some cases, takes several seconds per message.  The size of some of these folder is several hundred MBs.  My presumption is that when folders are large the process will tend to take longer (get folder - append message - save folder?).  Is this a correct assumption?

Thank you

Gordon

Can you give a little more detail on what you are doing:   Are you using IMAP?  Are these folders already open?  Are the messages large? Is the server local?

Sorry Paul, I should have been more explicit.  This is IMAP, the folders are not opened and the messages are not particularly large ... maybe typically 50KB.  The timing involved is probably about 3-4 seonds per message, if I drag a group of messages from the Inbox to a folder.  The server and client are both on my LAN.  The server machine is running Win XP SP3 and the client machine Win 7.  Both of the machines in question are reasonably fast (the server uses an AMD Athlon XP3200+ at 2.19GHz and the client a dual-core Intel E7400 at 2.8GHz). I should probably do an experiment by dragging (copying) to an already large folder versus doing the same to an empty folder.

Thank you

Gordon

For the experiment, put on session logging for the IMAP module.  It will give you a lot of output but it should show you where any delays are ocurring.

The experiment has been rather inconclusive.  I first copied 9 messages to a large folder (I don't know what the size is,but it contains over 3,000 messages).  It took 33 seconds to copy these messages ... they were each about 50KB or less.  I then turned on IMAP session logging and repeated the copy.  This time it was much faster!  It took about 4 seconds for all 9 to copy.  The session folder is MERCURY\IMAP_Ses.  When I looked in this folder, there were no recently dated files (the date-time on this machine is correct).  I don't know what happened to the session logging.  I then turned the session logging off and repeated the copying of the 9 messages and the time stayed at about 4 seconds.  This seems rather strange to me.

Gordon

[quote user="GordonM"]

The experiment has been rather inconclusive.  I first copied 9 messages to a large folder (I don't know what the size is,but it contains over 3,000 messages).  It took 33 seconds to copy these messages ... they were each about 50KB or less.  I then turned on IMAP session logging and repeated the copy.  This time it was much faster!  It took about 4 seconds for all 9 to copy.  The session folder is MERCURY\IMAP_Ses.  When I looked in this folder, there were no recently dated files (the date-time on this machine is correct).  I don't know what happened to the session logging.[/quote]

The files will have names 'TCPxxxx.mi' where xxxx starts at '0000' and increments in hex for each new IMAP conversation.

[quote] I then turned the session logging off and repeated the copying of the 9 messages and the time stayed at about 4 seconds.  This seems rather strange to me.[/quote]

That seems like about the expected time and the difference (from the original time) may be the effect of message caching in your client.

Paul - So far as I can see, the slow copying/moving only happens when the target is a large folder .... many messages and hundreds of MBs in size.  I should probably stop using these folders and start new ones.

It's stange that I haven't been able to find the log file that should have been recorded, but I'll look into that later.

Thank you

Gordon

[quote user="GordonM"]Paul - So far as I can see, the slow copying/moving only happens when the target is a large folder .... many messages and hundreds of MBs in size.  I should probably stop using these folders and start new ones.[/quote]

Do you have real-time anti-virus on these folders?  Perhaps they are being scanned and that is taking too long.

[quote]It's stange that I haven't been able to find the log file that should have been recorded, but I'll look into that later[/quote]

Is Mercury running with administrator rights?

I started this thread some months ago and never really found a clear answer at the time.  In fact, it seems that Paul was probably on the right track.  I am currently having to transfer several 100MBs of messages messages between two folders and at the present rate, it is going to take several days.  Even relatively small messages (e.g. less than 10K) are taking many 10s of seconds.  What I have discovered is that when I make the transfer, the process msmpeng.exe takes 100% or close to of the CPU time on the Mercury server machine.  Msmpeng.exe is the "malware protection engine" of Microsft Security Essentials (MSE), the anti-virus/malware application that I am using on that machine.  Turning off MSE's "real-time" protection speeds up the message transfer process enormously.

Googling this issue shows that it is a very common problem.  It seems that MSE has problems working efficiently when certain other applications are running.  Maybe Mercury is one of these.

It seems that, if I am to continue to use MSE, I will need to turn off real-time protection, maybe selectively for the Mercury installation folder.  It may also be possibe to use a "throttling" application to limit the resources being used by msmpeng.exe.

Gordon

[quote user="GordonM"]

I started this thread some months ago and never really found a clear answer at the time.  In fact, it seems that Paul was probably on the right track.  I am currently having to transfer several 100MBs of messages messages between two folders and at the present rate, it is going to take several days.  Even relatively small messages (e.g. less than 10K) are taking many 10s of seconds.  What I have discovered is that when I make the transfer, the process msmpeng.exe takes 100% or close to of the CPU time on the Mercury server machine.  Msmpeng.exe is the "malware protection engine" of Microsft Security Essentials (MSE), the anti-virus/malware application that I am using on that machine.  Turning off MSE's "real-time" protection speeds up the message transfer process enormously.

Googling this issue shows that it is a very common problem.  It seems that MSE has problems working efficiently when certain other applications are running.  Maybe Mercury is one of these.

It seems that, if I am to continue to use MSE, I will need to turn off real-time protection, maybe selectively for the Mercury installation folder.  It may also be possibe to use a "throttling" application to limit the resources being used by msmpeng.exe.

Gordon

[/quote]

The general advice is usually to exclude all of Mercury's directories from real-time anti-virus scanning.  Any delay in file access while Mercury is trying to process messages has been known to cause strange errors and other problems.  Use a specific product like Clamwall if you need to check inbound messages before users have access to them.

(I recall a thread recently that suggested that MSE had a command-line interface, so that could be used in a policy to scan messages.)

At the risk of insulting your intelligence, have you defragmented the disk on the server lately? I have found that Pegasus folder files and their indexes tend to have fragmentation problems, probably because they are appended to each time you add a message to the folder. Fragmentation causes the operations on the file to slow down as many (hundreds, even thousands) of separate disk pieces need to be read to access the folder.

If you don't want to defragment the whole disk, you can use a tool like 'contig' from www.sysinternals.com to defragment individual files, and see if that improves performance. I would try it on the .PMM and .PMI file that constitute a folder that is giving you grief and see if that makes a difference.