getplugins.php - 5.7s load time

[BloodyIron]

Please complete the following tasks.

• Web browser cache cleared
• Link provided to install script if applicable
• Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

Vivaldi, browser
Using: crazymax/rtorrent-rutorrent:latest

Tell us how you installed ruTorrent

crazymax/rtorrent-rutorrent:latest (k8s in yaml manifest via argoCD)

Describe the bug

When loading the webGUI getplugins.php takes 5.7 seconds to load EVERY time, and the page takes that long to load EVERY time.

Steps to reproduce

Literally load the page or refresh

Expected behavior

Load time in the realm of 5-15ms

Additional context

Original thread in other repo : crazy-max/docker-rtorrent-rutorrent#182

[stickz]

Hi @BloodyIron, this is probably specific to your configuration or hardware. What I suggest doing is installing vmtouch. It will take about 50mb of ram and hard drive space to cache the ruTorrent web client into memory.

If you're interested in steps for this solution, please provide more details about the hardware and operating system.

[BloodyIron]

Well it's a container, so that would be wiped away if it were to ever be re-initialised.

The container runs in a 3x node k8s cluster, each node in a VM on Proxmox VE (Linux KVM) with pretty good underlying hardware for the compute (one of the nodes is a Dell R720, the others are FX-8320 based).

The storage that backs the application aspect (not the torrent content) runs on a FreeNAS system with ZFS, and is striped-mirrored SSDs (4x total), and the network interconnects are multiple 1gige LACP bonds.

I do not realistically see any network, storage, CPU, or other forms of hardware contention. Multiple other websites I run on the same infra run substantially faster, and it's strictly this one php file that drags its heels.

[stickz]

@BloodyIron Any update on this issue? Did you upgrade to ruTorrent version 4.0 stable through your docker install script? Have you tried anther web browser (such as Google Chrome)? This could be a web browser problem.

There are web developer tools on chromium you can use to debug this issue. You can record the web page for 10 seconds while it loads, then get detailed information about what is causing the problem.

[BloodyIron]

@stickz well this is a new one, a developer haunting me for an update! haha! XD I love it!

Okay. so I wasn't aware that crazy-max ( https://github.com/crazy-max/docker-rtorrent-rutorrent/releases ) had released a new version (plus I've been AFK for the last 4-ish days). So I'll try that image after I send this message. Just to clarify though this isn't... "my" script or anything like that. I'm simply using the docker image in kubernetes, feeding it settings, and that's about it.

As for other browsers, I can't remember which browsers I tested it with, but I can test again with multiple browsers, and as a point of relevant interest my primary browser is Vivaldi, which is a Chromium derivative (but I can test Firefox/others too).

As for the developer console, that's how I was able to get the loading time for this file in the first place. I didn't record the waterfall load, I would just have the developer console open, then load the page, then watch and review.

I'll switch to the new image shorty and report back. By the way, seriously loving your support here! Thanks a tonne! :)

[BloodyIron]

@stickz okay so I had to explicitly use "crazymax/rtorrent-rutorrent:4.0-0.9.8-0.13.8" as I wasn't sure if "latest" was actually delivering the new ruTorrent... and now I have v4.0 running, however the problem persists. In all three tests below, I was using incognito mode, and was also ctrl+f5'ing to force any cache drop/regeneration.

Load times of getplugins.php:

• Vivaldi: 7.48s
• Firefox: 7.28s
• Chrome: 11.64s

I don't know why Chrome had a spike in load times, but yeah... here we are... And these load times were really the same after multiple refresh/reload/ctrl+f5's, so it doesn't look to be a load-once problem.

I also want to clear up that this is not an underlying hardware issue (so far as evidence shows), as I have other containers running websites (like argoCD, for example) which load substantially faster (500ms in the example of argoCD). And I do not observe any CPU, RAM, networking, or disk contention that could contribute to this (especially since the majority of this content is likely cached in RAM by the container, speculation though).

I would like to add, however, that there are rendering issues in Vivaldi. I do not know why they happen. I will not be posting a screenshot (as well... there's sensitive information), so I'm going to describe it as best I can. This rendering issue does not seem to happen in Firefox or Chrome so yeah...:

1. In the "State" section, the icons are repeated for the full width (and beyond) of that sub-section
2. The "bubbles" showing # of torrents, plus size per label/tracker, is dark-ish grey text, on a light-ish grey background, extra hard to read (this appears to be limited to the left bar, but is present in State, Labels, Search, and Trackers).

I'm going to roll back to the pre-v4.0 image as I want to be able to read this text, but should you want me to test more, then I gladly will :)

[stickz]

@BloodyIron

1. If you would like to do more testing, I would recommend using the web developer tools on Chrome. You can record a page refresh. I would like to see a screenshot of the network waterfall in the performance tab. I'm specially interested in getplugins.php You can use the snipping tool to only capture the web developer tools. You will be able to preview the image before posting it and only capture a specific section of your screen (so sensitive information is not exposed).

2. Setting $do_diagnostic to false in /conf/conf.php will improve your loading time, at the expense of less debugging information. It's safe to change this value, once your ruTorrent installation is working properly.

3. We never recommend using version 3 anymore because it's full of bugs and performance issues. If you're not able to provide screenshots to help us improve support for Vivaldi, I would recommend using Firefox or Chrome instead. It's worth it to change web browsers for version 4. It's significantly more polished and will result in a much smoother experience.

[BloodyIron]

Hi @stickz

Oddly enough, switching back to crazymax/rtorrent-rutorrent:4.0-0.9.8-0.13.8 the previously mentioned graphical issues in Vivaldi don't exist... and it's confusing lol. Let's just ignore that for now and if it happens again I'll try to provide something actually useful around that (for now I'll keep crazymax/rtorrent-rutorrent:4.0-0.9.8-0.13.8 as my daily driver).

As for your screenshot requests... here's the one you asked for:

Here are two additional ones that are not what you asked for but may be helpful anyways... :

As for the conf.php file, that file doesn't exist in the docker image except under folders for different plugins, so I'm unsure the "proper" way to do that with this particular container... What kind of performance timing difference are we talking about here for disabling $do_diagnostic ? Is that an environment variable I can pass to it perhaps?

[stickz]

The file does exist, it's right here. ruTorrent will not function without it. $do_diagnostic = false; could have a major impact.
https://github.com/Novik/ruTorrent/blob/master/conf/config.php

Also, while you're in there, ensure $phpUseGzip = false; is set. Enabling PHP gzip could cause this problem to happen.

[BloodyIron]

Okay I found the config.php file, I somehow missed it first time I looked and it wasn't quite where I anticipated it in the container (despite searching the whole root/recursive file structure). Anyways...

phpUseGzip is set to false, do_diagnostic is set to false, and getplugins.php is still averaging about 5.7s load time

I have explicitly confirmed those variables are set to false in the running config.php

[n1ce-0ne]

sorry to butt in, im just reading along / following / happy to help if i can, im just wondering BloodyIron,
as per this comment here: #1878 (comment)

have you tried disabling plugins or 'moved' plugins like they call it, to try narrow down which if any are causing it?

i ask because they seem to have identified which plugin is actually causing it 'extsearch' in there case.

if that could be possible in your case maybe it could help?

ignore me if not, just enjoy this sorta stuff :)

[BloodyIron]

@n1ce-0ne yeah I had seen that particular one suggested as disabling, so these are the ones that I've had disabled this whole time:

diskspace,extsearch,feeds,filedrop,geopip2,ipad,rss,rssurlrewrite,unpack

[liaralabs]

I'm currently facing a similar issue on a multi-tenant box.

ruTorrent is hosted on an SSD drive, rTorrent is hosted on individual drives.

For several users, ruTorrent getplugins.php loads sub 1 second, with every plugin loaded. However, two users sharing the same drive are facing ~6 second script times for the getplugins.php script.

Underlying drive has almost zero activity, so it doesn't seem to be directly related to disk activity on the underlying rTorrent (xmlrpc) device.

If I disable the FileManager plugin, load times go to 3 seconds (still high). Other users on the server are able to have 1 second load times even with FileManager enabled.

That said, a slow trace is largely indicating that the stack time is getting spent caught in the xmlrpc calls:

[27-Jan-2023 21:49:34]  [pool user] pid xxxxxxx
script_filename = /srv/rutorrent/php/getplugins.php
[0x00007f360a2147f0] fread() /srv/rutorrent/php/xmlrpc.php:110
[0x00007f360a2146a0] send() /srv/rutorrent/php/xmlrpc.php:184
[0x00007f360a2145c0] run() /srv/rutorrent/php/getplugins.php:176
[0x00007f360a2144c0] findRemoteEXE() /srv/rutorrent/plugins/filemanager/init.php:28
[0x00007f360a214390] [INCLUDE_OR_EVAL]() /srv/rutorrent/php/getplugins.php:495

Disabling FM still gets caught in xmlrpc time

[27-Jan-2023 22:16:42]  [pool user] pid xxxxxxx
script_filename = /srv/rutorrent/php/getplugins.php
[0x00007f14bb614870] fread() /srv/rutorrent/php/xmlrpc.php:110
[0x00007f14bb614720] send() /srv/rutorrent/php/xmlrpc.php:184
[0x00007f14bb614640] run() /srv/rutorrent/php/getplugins.php:176
[0x00007f14bb614390] findRemoteEXE() /srv/rutorrent/php/getplugins.php:403

ruTorrent version is v4.0-beta3 for all users.

Honestly, can't explain anything beyond potentially some weird intra-drive differences in the ability to make xmlrpc calls to the rTorrent interface, even though the drive itself is mostly idle.

[stickz]

@liaralabs @BloodyIron Please give aeb9f62 a try and set $localHostedMode to true in the config.php file.

[liaralabs]

I just cherry-picked the commit to the install in question and it seems to have made some improvement. 2.5 seconds with filemanager and 1.4 or so with it disabled.

Still some time spent in the unpack plugin (same with filemanager).

Took a peek at findRemoteEXE() /srv/rutorrent/plugins/unpack/init.php:11 and realized that was because do_diagnostic. With do_diagnostic false and localhostedmode true, I get 500ms load times on the page now with filemanager disabled. Nice work!