WebUI locks up/gets incredibly slow when there are many torrents

[gonX]

Running 1.2.0_dev on my seedbox, my own computer locks up (with fairly decent specs) during the load of the WebUI, after having typed in the password.

I've tested this under Chromium b27944, latest Opera, latest Firefox and latest Epiphany.

I have around 300 torrents seeding, and it works fine in the 1.1.9 WebUI under both Ajax, white and classic. The CPU usage is fine under 1.2 on the seedbox itself (around 5%), and I can see that it's actually seeding with the console UI, but the CPU usage on my main computer flies to 100% after it's starting to load.

[damoxc]

If someone experiencing this would tar up their config folder it would assist in tracking down this issue.

[bckspc]

I have about 200 torrents seeding and when I try to open the web interface, it takes ages to load (after inserting the password and connecting) and all browsers I've tried (IE 7 / 8, Firefox Win / Mac, Safari Win / Mac, Chrome) all almost crashes the browser and after a while I get the error message that a javascript is taking to long to respond and I can continue or stop the script. If I wait long enought (several 'continue' clicks) I can see the torrents but since the interface refreshes every minute or so, I cannot do anything. This happens both with remote connections and local connection.

You can now say that I have many torrents and that's why it's so slow. I agree that that must be to problem, but the annoying fact is that the WebUI from 1.1.9 worked perfectly even connect from outside my LAN. Another strange thing is that until version 1.1.9 I could not use deluge-gtk (win or linux) remotely because I had many torrents and the interface was very slow (locally worked fine). Now on version 1.2.0 rc3, I can use the gtk interface remotely without any problems, it's not slow anymore (and I'm still talking about 200 torrents or so).

What I don't understand is that if deluge 1.2x uses a new method to connect (RPC) no matter the interface, then it should be slow on all interfaces or fast on all the interfaces. Why is the Web UI so slow if it can be so fast using GTK?

One more note, I tried the webui with just one torrent and the webui was working fine, so definitely the problem is the number of torrents.

(I'll attach my config dir as soon as I get home)

[bckspc]

What do you need exactly from the config folder? Do you want all the state files and dir (with all the torrents) and also the authentication files? Or can I skip this ones? :)

Replying to damoxc:

If someone experiencing this would tar up their config folder it would assist in tracking down this issue.

[damoxc]

It's because the webui is largely written in javascript, and I haven't been through optimising every last bit of the code. I have a config folder now (with 350ish torrents in) so when I get some time I can sit down and sort this out for you guys. Apologies that it's happening in the first place, I've never really had any more than 20 torrents loaded at a time so didn't notice it until it was too late!

[wohali]

Definitely a problem, WebUI is unusable in 1.2.0 with anything like 100 torrents going. Consider this a vote to increase priority on fixing this :)

[gonX]

It would be very nice if this got fixed in the very near future. As a temporary solution I connect directly to the daemon with the GTK client, but that isn't a solution for when I'm away from my house, considering sending info of +1000 torrents isn't really suitable for a 1mbit upload. (and yes you might argue that +1000 torrents on a 1mbit pipe is overkill. It isn't, because everything I seed on is already well-seeded, and I have the space for it.)

[mikechelen]

Replying to damoxc:

It's because the webui is largely written in javascript, and I haven't been through optimising every last bit of the code. I have a config folder now (with 350ish torrents in) so when I get some time I can sit down and sort this out for you guys. Apologies that it's happening in the first place, I've never really had any more than 20 torrents loaded at a time so didn't notice it until it was too late!

Any ideas where the slow portion of Javascript code is?

[leoric]

One more note, I tried the webui with just one torrent and the webui was working fine, so definitely the problem is the

Moreover, this problem is related to the number of torrents currently being shown in UI - if you switch to a label with not so many torrents, browser immediately becomes responsive and cpu load drops.

[Cro_Crx]

I'm running into the same problem. I managed to profile some of the JavaScript? code to check for any bottlenecks. I set Deluge.debug to false in the console, Is set to true in my build (1.3.0-dev). Seems like 60% of the usage is coming from a function within the ext-all-debug.js file. Line 33261 which contains the function

syncFocusEl : function(row, col, hscroll)

In total 78% of the time is spent within the ext-all-debug javascript file. Hope this helps.

[andar]

There has been lots of work in trunk to address this issue, perhaps you could try using the trunk version and see if it has improved the situation for you.

[damoxc]

I'm closing this as the UI now loads fine with 1000 torrents.

​http://www.imagebam.com/image/937fe665804373

[bckspc]

When will it be added to release version? Version 1.2.1. still has the problem and the change log for 1.2.2 doesn't mention this bug fix.

[damoxc]

It's fixed in git master, and will be in the 1.3 release.

[bckspc]

Is there anyway to replace the buggy .js files in the current version?

[damoxc]

No, extjs has been upgraded in 1.3.

[damoxc]

Do you have any reason not to try using 1.3?

[bckspc]

I'm downloading from source now. The only problem is that everytime I change the deluge version I lose some torrent information or I have to deal with some crashes before I starts to work again. I was just looking for a quick fix to avoid all this trouble.

[damoxc]

The change from 1.2.1 to 1.3 is not as drastic has it has been in the past few releases, you should be okay. I certainly haven't lost anything and I keep switching between 1.2.1 and 1.3.

Of course report any faults you find so we can get them fixed!

[bckspc]

Just on question, I know this isn't the place but... I got the git master. After compilation I got version 1.2.9. Is 1.3 a branch? which one?

[damoxc]

No that's 1.3, the version is actually 1.2.900 (iirc), the first rc will be 1.2.901, second 1.2.902 etc.

[bckspc]

thanks! :) starting my beta testing...

[eatnumber1]

I'm still getting this.

deluge-web: 1.3.3
libtorrent: 0.15.9.0

[eatnumber1]

I can send someone my torrent dir, but I'd have to know where to send it. I have about 1500 torrents added.

[Cas]

Replying to eatnumber1:

I'm still getting this.

deluge-web: 1.3.3
libtorrent: 0.15.9.0

This is a 2 year old bug report please open a new one with precise details of what you are encountering.

[eatnumber1]

Replying to Cas:

This is a 2 year old bug report please open a new one with precise details of what you are encountering.

I've opened a new bug at #2042