[OpenAFS-devel] Performance of Thunderbird on windows with mail folders stored in AFS

[Douglas E. Engert]

A followup on this thread.

https://bugzilla.mozilla.org/show_bug.cgi?id=769346

has been accepted and resolved. The patch buffers the output
of a copy, including a delete that copies to the trash.
This makes TB performance much more acceptable.
It is still slow whole reading mail to the local folders as
there may be other places where buffering could help.
(First thing in the morning, I start a "Get Mail" then go for coffee.)

But does not address the AFS overhead of a write operation,
just cuts down the number of write operations from TB.


On 7/2/2012 1:17 PM, David Karger wrote:
> I write to confirm that this problem is not limited to windows; I'm having exactly the same trouble using TB13.1 on my debian install.
>
> On 6/29/2012 11:58 AM, Douglas E. Engert wrote:
>>
>>
>> On 6/28/2012 11:31 PM, Jeffrey Altman wrote:
>>> On 6/28/2012 4:21 PM, Douglas E. Engert wrote:
>>>> The best I can tell, Thunderbird for the local mail folders is doing
>>>> synchronous writes, which is another performance problem in itself,
>>>
>>> SysInternals Process Monitor will tell you exactly what thunderbird.exe
>>> is doing.
>>
>> Yes, I have been doing that.
>>
>> Using 1.7.1100, the TB "Move To" of a 3.8MB mail message with an excel
>> attachment, I see some 49,000 writes of 74 bytes that take more then 0.001
>> seconds each. These writes account for 91% of the data and at best 0.001
>> seconds each account for at least 49 seconds of the 60 seconds to copy
>> the file.
>>
>> If TB buffers the output using an 8K buffer, its more like 490 writes,
>> and the copy takes less then 2 second (by my watch) which is acceptable.
>>
>> So the overhead appears to be in the write operations and not in the
>> amount of data.
>>
>> So even though the writes/second is about 819, the big problem is
>> Thunderbird's not buffering the data.
>>
>> (I have not tried writing a test program to write out 3.8MB of data
>> at 74 bytes each, to see if there may be still be some other Thunderbird
>> issues. I can't do anything on this next week, but will try the week after.)
>>
>>>
>>>> although it looks like a Delete/Copy/Move has its own thread (or its using
>>>> the main thread which might be way it is not responding)  but as
>>>> a user, deleting messages (that get copied to the Trash folder)
>>>> it becomes single threaded waiting on the Trash folder and I have to wait
>>>> to do the next delete.
>>>>
>>>> Note that by buffering I get about 60 times improvement in throughput,
>>>> so the performance hit is caused more by the number of writes, not on how
>>>> much data is written.
>>>
>>> That makes sense because for each write an extent exchange with the
>>> afsd_service is going to take place.
>>>
>>>> Could Windows be doing some throttling based on the number of writes?
>>>
>>> Unlikely.
>>>
>>>> I don't get this bad of performance using the Windows DFS as I do AFS.
>>>
>>> DFS only uses the Windows page cache.  It doesn't have a cache of its own.
>>>
>>>> CPU time, I/O and network I/O are NOT maxed out during one of these
>>>> Delete operations.
>>>
>>> I wouldn't expect them to be. Thunderbird is serializing one request at
>>> a time.
>>>
>>>
>>> There are many things that could be done to further improve performance
>>> in the extent management interfaces.  However, my focus has been on
>>> application compatibility and stability.  Those are the areas which the
>>> small number of organizations contributing to Windows client development
>>> consider to be the priority.
>>
>> Understand.
>>
>>>
>>> Jeffrey Altman
>>>
>>
>
>
>

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444