Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#1026 closed bug (Fixed)

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

Reported by: gonX Owned by: damoxc
Priority: critical Milestone: 1.3
Component: Web UI Version: 1.2.0_dev
Keywords: lockup crash freeze lock Cc: russ@…

Description

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.

Change History (28)

comment:1 follow-up: Changed 8 years ago by damoxc

  • Status changed from new to accepted

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

comment:2 Changed 8 years ago by damoxc

  • Milestone set to 1.3.0

comment:3 follow-up: Changed 8 years ago by 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)

comment:4 in reply to: ↑ 1 Changed 8 years ago by bckspc

  • Cc antonio.mertens@… added

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.

comment:5 Changed 8 years ago by bckspc

  • Cc antonio.mertens@… removed

comment:6 follow-up: Changed 8 years ago by 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!

comment:7 Changed 8 years ago by 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 :)

comment:8 Changed 8 years ago by 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.)

comment:9 in reply to: ↑ 6 Changed 8 years ago by 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?

comment:10 in reply to: ↑ 3 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by 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.

comment:12 Changed 8 years ago by 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.

comment:13 Changed 8 years ago by damoxc

  • Resolution set to fixed
  • Status changed from accepted to closed

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

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

comment:14 Changed 8 years ago by 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.

comment:15 Changed 8 years ago by damoxc

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

comment:16 Changed 8 years ago by bckspc

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

comment:17 Changed 8 years ago by damoxc

No, extjs has been upgraded in 1.3.

comment:18 Changed 8 years ago by damoxc

Do you have any reason not to try using 1.3?

comment:19 Changed 8 years ago by 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.

comment:20 Changed 8 years ago by 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!

comment:21 Changed 8 years ago by 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?

comment:22 Changed 8 years ago by 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.

comment:23 Changed 8 years ago by bckspc

thanks! :) starting my beta testing...

comment:24 follow-up: Changed 6 years ago by eatnumber1

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm still getting this.

deluge-web: 1.3.3
libtorrent: 0.15.9.0

comment:25 Changed 6 years ago by eatnumber1

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

comment:26 Changed 6 years ago by eatnumber1

  • Cc russ@… added

comment:27 in reply to: ↑ 24 ; follow-up: Changed 6 years ago by Cas

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:28 in reply to: ↑ 27 Changed 6 years ago by 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

Note: See TracTickets for help on using tickets.