User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:184.108.40.206) Gecko/20101203 Firefox/3.6.13 Build Identifier: 220.127.116.11 (20090812) I was sending a 21M file and it was (still is) taking 'forever'. I'm using Imap, and the extension is an a network share, which exacerbated the problem. But problems noticed using a 'wireshark' dump: 1) SMB read size is only reading in 16K chunks. This should be increased to 16M. The read speed @4K/s over a dedicated 1Gb net is < 0.25 MB/s, or less than 0.3% of expected (max *measured* is 119MB/s, using cygwin's "dd" program to read from a network file). The 2nd problem is the network I/O size of <8K. This also gives low I/O, on the order of < 0.3MB (also <0.3% network usage). To send this file, would have taken (it crashed trying to send it due to it trying to *also* save a 80MB message I was composing at the same time -- adding 280 seconds to the cycle): 1) 90s to read pdf from disk(net) 2) 70s to send to sendmail 3) +90s to read again (needed to read attachment twice!) 4) 70s to copy to sent folder (send to IMAP) --- total: 320s, or over 5 minutes. My 'save copy' time is 5 minutes, so it triggered as well, trying to save my "work", adding more time. A 2nd message that was open in compose had an 84MB attachment and had also started saving -- something that would have taken 280s. This is completely unacceptable performance when all I/O is 'local' (local, including a 100+MB I/O network -- that's megabytes, not megabits, and the actual measured maxumums are 125MB write, 119MBread). Reproducible: Always Steps to Reproduce: 1. Put large (~20MB) file on local share (w/+tuned+ network I/O so it's not a drag; note that local network is 1Gb) 2. Use IMAP and try to send file. 3. Note that Tbird uses <0.3 - 0.4% max of network bandwidth and takes *WAY* to long to send file. At over 320 seconds to send the file, that's over 320 times as long -- but at 3m20s, the process hung. Actual Results: tbird hung trying to send file due to slow I/O (likely due to trying to 'save' work of file being sent or 2nd file in compose buffer (84MB in len). Expected Results: 20MB file should transfer to my local server with all I/O done, in a few seconds. If I/O was optimized, it would take <1 second. With gmail having over 6G of space, sending a multi-meg file shouldn't be unreasonable. But Tbird's perf
We aren't working on 2.x anymore !!!! Closing as wontfix !
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
L A Walsh, Version 3 is considerably different from version 2. But if this affects version 3.1 in a similar way, please update the bug. Stats based on trunk builds would be even better. Thanks.
You need to log in before you can comment on or make changes to this bug.