Performance issue when seeding a lot of torrents

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Seed 800+ torrents on a lame hardware device such as DNS-323.
2. Have one torrent downloading.
3. Have some means to monitor traffic to that device. I use my router running 
tomato.
4. Connect to the transmission daemon with transmission-remote-gui.

What is the expected output? What do you see instead?
As soon as you connect, transfer speed takes a nose dive. In my case, from 
~4000bps to ~400bps (that's bit per second).
As soon as you close/disconnect transmission-remote-gui it gets back to normal.
Most importantly: This does not happen when connecting with the default web 
interface.

My guess is that transmission-remote-gui hammers transmission daemon with 
update requests.

What version of the product are you using? On what operating system?
v5.0; transmission daemon 2.80 on DNS-323 running Alt-F (alternative firmware) 
version 0.1RC3.

Please provide any additional information below.

Original issue reported on code.google.com by smurf...@gmail.com on 14 Nov 2013 at 12:28

[GoogleCodeExporter]

Increase the update interval to 10 seconds.
Hide unneeded columns in the torrents list.
It should help to decrease RPC traffic/load.

Original comment by j...@cp-lab.com on 14 Nov 2013 at 3:24

• Changed state: Feedback

[GoogleCodeExporter]

Thank you for taking the time. I'll try what you suggested.
A bit more info (from me) is in order: I, currently, have 12 columns showing 
and 23 torrents visible in the list. Compare that to the web interface, in 
compact view, which has 30 torrents visible. That didn't seem to affect 
performance.
I can't say what's the update interval it uses.

If I remember correctly, I don't think that switching to the downloading or 
active torrent list, which consisted of just one torrent, improve the 
performance, but I could be wrong. Will try it again next time I need to snatch 
something.

Do you only fetch info for those visible torrents or for all 800+?

Other than the workaround you suggested, is there any more information you'd 
like me to provide, or maybe something you'd like me to try?

Original comment by snoib...@gmail.com on 14 Nov 2013 at 5:28

[GoogleCodeExporter]

Info for all your 800 torrent is requested during each refresh. The only option 
is to minimize data packet size is to hide unneeded columns.
Also increase refresh interval to minimize queries to the daemon.

Original comment by j...@cp-lab.com on 14 Nov 2013 at 5:53

[GoogleCodeExporter]

If I may so bold and make a suggestion: Why not request info for just the 
torrents that are visible?

Original comment by smurf...@gmail.com on 14 Nov 2013 at 5:59

[GoogleCodeExporter]

...I should've add that I have the "added on" column visible and that the 
torrent list is sorted by that column in descending order.
So in this case, probably others where the value of the sort column does not 
change - my suggestion may make some sense.

Original comment by smurf...@gmail.com on 14 Nov 2013 at 6:06

[GoogleCodeExporter]

@smurf -- Since the decision on what to show comes from the torrents 
themselves, how would you know which ones to show, if you didn't query the 
whole bunch?

I.e. @each refresh, what torrents are showing may change -- the only way to 
know is to read the status of all of the torrents.

Possible suggestion -- based on my own experience.  I wanted more control over 
the priority.  So I run a 2nd instance of transmission and my torrents are 
split between the two.  That way I can keep up transmission-remote and it 
doesn't have to communicate as much.

Original comment by astara.a...@gmail.com on 15 Dec 2013 at 10:29

[GoogleCodeExporter]

2 instances may be a bit too much for my NAS to handle.
At least the way I use it, sorted by a torrent value that doesn't change (added 
on) - Unless I add a new torrent, the torrent ordering doesn't change and, 
therefore, there's no need to read all the torrent's data.

But even if you sort it differently, why not perform the UI update in three 
steps:
1. For all torrents read just the value for the sort column(s).
2. Sort the data received and and calculate which torrents will be displayed.
3. Fetch all the data for all the columns but just for those torrents from step 
2.
4. Update the UI.

Correct me if I'm wrong, but that should scale well with both a large number of 
torrents and a lot of columns displayed.
Provided, of course, that such APIs are available to do step 1 and 3.

Original comment by smurf...@gmail.com on 24 Dec 2013 at 1:05

[GoogleCodeExporter]

Yes, there is some room for improvements, but it is not high priority...

Original comment by j...@cp-lab.com on 4 Jan 2014 at 11:13

• Changed state: New