Thousands of torrents

[dudumomo]

First of all, I'd like to thanks everyone for their jobs.
The new release 1.3 is quite good !
Far better than the 1.2 version which in my case had a lot of problem of supporting a lot of torrents.

But it seems that 1.3 still got issues....(Well...quite high limit in fact)
I'm actually sharing thousands of file (4000 torrents active) on an optic fiber connection....and since may be the num 3xxx my system are quite slower and slower the more I add torrents.
Deluge is now using a full core on my Ubuntu 64b with amd x6.

Any tips to increase the amount of active file ?

Actually I'm sharing Creative Commons OGG albums from Jamendo and I there is still plenty torrents to add.
But not many peers so far. So I don't really know what to do...

[keepitcomplicated]

I would really like to know more about this... just switched from Win+uTorrent to Ubuntu+Deluge on the seed-box, and I'm expecting well over 3000 torrents to be added to it over the next couple of months.

[devmage]

I'm also interested in this. I have been running a headless Ubuntu seedbox with ~1000 torrents for the past few months, and have noticed terrible (100%) CPU usage whenever the GTK client is connected either locally or remotely. By contrast, deluged itself only uses ~15% CPU on an Atom N270. I anticipate having more torrents in the near future, as well.

Keep up the great work!

[keepitcomplicated]

@devmage

Did the CPU usage increase by each torrent, or did it happen around a certain number?

[devmage]

@keepitcomplicated

I, like you, switched from a Windows seedbox to this Ubuntu box. At the time of the switch, I had about 800 torrents going. It exhibited this sluggish behavior in the GTK remote and local clients, both of which I attributed at the time to network congestion ("oh, it's just the wifi", "it's the overhead of running apps over a remote NX session", etc.).

I happened one day to have top open in an ssh session alongside the GTK remote client, and noticed that deluged was eating every last cycle. I was intrigued, so I closed the remote client and it dropped down to the ~15% it had been using prior. I opened an NX session and there opened the GTK local client, and saw the same spike in CPU use - this time it was compounded by the client itself trying to hog the CPU!

So, short answer, it started around 800, but I also started around 800. I don't really have a baseline other than that.

EDIT: I've upgraded the Ubuntu box to 10.10, with libtorrent-rasterbar 0.15, and the interface is relatively more usable. I can post some more detailed stats, if desired.

[keepitcomplicated]

@devmage

I'm running 10.10, just going past 500 torrents now and deluged is between 17% and 20% — goes up to 30% when the GTK is running remotely.

I'm testing a native Mac OS X client that my friend just put together, and it seems to be using less CPU, around 22-24%.

[devmage]

@keepitcomplicated

Native OSX client?! Tell your friend to start a Google Code project for that or something, stat! I'd love to help test out a binary, and may even be able to contribute to its development (time permitting). I've been using the GTK client as compiled through macports, but a true Cocoa interface would be lovely.

[keepitcomplicated]

@devmage check it out here: http://forum.deluge-torrent.org/viewtop ... 40#p149477

this is very basic at the moment, a weekend project... it will be released in a few days on github

[devmage]

If you're experiencing better deluged performance with a different client, it seems to suggest that it's a function of how the two clients poll the daemon. I've found slightly better daemon performance (80% CPU instead of 100%) by removing the Up and Down Speed info columns in the GTK client; I'm presuming that, without them, the client doesn't poll the daemon for that information.

Without more granular control over the refresh rate of the GTK interface (save for delving deep into the source), it's hard to test this.

[Tobias]

Middle-of-the-road performer, but it does get lots of development love.