Opened 13 years ago

Last modified 5 years ago

#1999 new bug

WebUI uses 100% CPU loading TorrentInfo for thousands of files

Reported by: dalek Owned by: Damien Churchill
Priority: minor Milestone: performance
Component: Web UI Version: 1.3-stable
Keywords: cpu web gtk Cc: dale@daleking.org, Bro, marsjaninzmarsa@gmail.com, krichter@posteo.de

Description

Hi,

Just switched to Deluge from utorrent/linux and would like to say thanks for making it open source.

The problem I have is that when I initially connect with the WebUI (or the console-ui) the process sits at 100% CPU for tens of minutes.

I'm only seeding a handful of torrents via a private tracker but that equates to around 300,000 files on disk contained in those few torrents.

I ran the WebUI with --profile and it looks like the cause is the TorrentInfo() routine in deluge/ui/common.py.

The problem I think is that when the WebUI gets a connection, it loads in to RAM every filename contained in each torrent. This causes RAM to be used excessively (my deluge-webui process gets to ~200MB). On top of that, for each filename, it runs through a UTF decoding routine in rencode.py which seems to be burning the CPU.

After tens of minutes, when the filename info is loaded, the WebUI comes back to life. That is, unless you click on the 'files' tab for one of the torrents with tens of thousands of files, then it hangs for ages. (I guess as expected).

I'm not a python programmer, but to fix this issue I think you could:

  • change class deluge.ui.common.TorrentInfo to not load filename/filedata info when the class is created.
  • instead, load filename/filedata info on demand via function in that class.
  • instead of loading _all_ filename/filedata info, just load say 10-20, with a flag indicating more filename/filedata info is available if there are more files than that in the torrent.
  • in the WebUI, only load 10-20 files at a time, and present a 'next' button to load the next 10-20 filenames in the 'file' tab.

Although I have only a few torrents but with hundreds of thousands of files, I think this problem is similar to others in the tracker where people have several thousand torrents, maybe with less files in each.

I'm running on Debian testing, 32bit:

libpython2.7 2.7.2-8 python2.7 2.7.2-8 python-twisted-{bin,core} 11.0.0-2 python-twisted-web 11.0.0-1 deluge-{console,common,web}, deluged 1.3.3-2

Attached is the profile output. I can provide the profile file if needed. It was run during the first half minute or so of the webui spinning at 100% CPU. It continues like this for tens of minutes (I can time it if needed):

>>> import hotshot, hotshot.stats
>>> stats = hotshot.stats.load("/opt/deluge/.config/deluge/deluge-web.profile")
>>> stats.strip_dirs()
<pstats.Stats instance at 0x8ebd6ac>
>>> stats.sort_stats('time', 'calls')
<pstats.Stats instance at 0x8ebd6ac>
>>> stats.print_stats(20
... )
         54843249 function calls (51486080 primitive calls) in 126.991 seconds

   Ordered by: internal time, call count
   List reduced from 579 to 20 due to restriction <20>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 13996456   23.969    0.000   37.435    0.000 rencode.py:220(f)
3356933/101   22.898    0.000  100.112    0.991 rencode.py:263(f)
      162   22.732    0.140  126.051    0.778 selectreactor.py:93(doSelect)
 16792062   16.913    0.000   16.913    0.000 utf_8.py:15(decode)
      402   14.208    0.035  100.024    0.249 rencode.py:171(decode_list)
  2795602    8.630    0.000   12.077    0.000 rencode.py:153(decode_string)
  6312624    3.894    0.000    3.894    0.000 rencode.py:251(f)
  4576888    3.849    0.000    3.849    0.000 rencode.py:135(decode_intl)
  4311445    3.488    0.000    3.488    0.000 rencode.py:131(decode_inth)
      105    2.659    0.025  102.783    0.979 client.py:128(dataReceived)
  1508477    1.160    0.000    1.160    0.000 rencode.py:143(decode_float32)
  1161239    1.039    0.000    1.039    0.000 rencode.py:139(decode_intq)
        1    0.920    0.920    0.922    0.922 config.py:393(save)
      127    0.449    0.004  103.301    0.813 tcp.py:443(doRead)
      168    0.053    0.000  100.109    0.596 rencode.py:178(decode_dict)
       41    0.037    0.001    0.037    0.001 __init__.py:827(flush)
    14030    0.012    0.000    0.012    0.000 rencode.py:127(decode_intb)
        5    0.007    0.001    0.007    0.001 gettext.py:343(gettext)
        2    0.004    0.002    0.005    0.002 sre_compile.py:301(_optimize_unicode)
      162    0.003    0.000    0.936    0.006 base.py:755(runUntilCurrent)


<pstats.Stats instance at 0x8ebd6ac>

Thanks again for this client! Any help on the above would be appreciated.

Regards, Dale

Change History (8)

comment:1 by dalek, 13 years ago

Cc: dale@daleking.org added

comment:2 by Calum, 12 years ago

Milestone: Futureperformance

comment:3 by Bro, 9 years ago

Cc: Bro added

Add bro to cc

comment:4 by HellFire, 8 years ago

This also applies to the GTK UI too. File lists should be loaded on demand, not on connect. I tried switching from rtorrent and had to switch back because the amount of files loaded made the WebUI unusable and the GTK UI took over 10 minutes to connect and was quite unstable.

comment:5 by Kuba Niewiarowski, 7 years ago

Cc: marsjaninzmarsa@gmail.com added

comment:6 by Karl Richter, 7 years ago

Cc: krichter@posteo.de added

comment:7 by int3l, 5 years ago

Keywords: web gtk added
Summary: 1.3.3 WebUI uses 100% CPU loading TorrentInfo for thousands of filesWebUI uses 100% CPU loading TorrentInfo for thousands of files
Version: 1.3.31.3.15

comment:8 by int3l, 5 years ago

Version: 1.3.151.3-stable
Note: See TracTickets for help on using tickets.