Open GoogleCodeExporter opened 9 years ago
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
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
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
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
...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
@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
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
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
Original issue reported on code.google.com by
smurf...@gmail.com
on 14 Nov 2013 at 12:28