Page 2 of 2

Re: Optimizing SABnzbd

Posted: May 29th, 2019, 8:12 am
by Puzzled
I've done some experimentation on the impacts of sleeping in the downloader loop in Windows.

First, the granularity of sleep using a loop that runs 1 sec and tests how many times it runs with various sleep lengths:
time.sleep(0.0001): 516
time.sleep(0.001): 516
time.sleep(0.002): 343
time.sleep(0.005): 173
time.sleep(0.01): 95
time.sleep(0.1): 10

So there is no point in sleeping shorter than 0.001, which in reality averages to 0.002. This is an OS limitation so I think it will be fairly consistent no matter what the cpu speed is.

I also printed how long each sleep lasts, and almost all of them last about 0.00195 seconds.

The receive buffer for SSL is 16 KB. When I tested this by setting the delay to 0.2 seconds and tried various number of connections, this seems to be what limits the speed:
5c = 350KB/s
10c = 700KB/s
20c = 1600KB/s

At 500 iterations/second (with 0.001 sleep each iteration) this should result in a little under 8 MB/s/connection.

TLDR: Even with sleep and SSL it is theoretically possible to fill a 1 gigabit line using 15 connections on Windows.

Re: Optimizing SABnzbd

Posted: May 30th, 2019, 3:35 pm
by Puzzled
I have put the changes for fetching multiple articles and putting them in a server queue here: https://github.com/puzzledsab/sabnzbd/t ... multifetch
This will mostly be an advantage for low power servers and/or high bandwidth. It also makes the sleep patch more efficient because the time consuming part of fetching articles will be done more rarely.

The server queue needs to be purged and the relevant try lists reset when the server is shut down. I have put it on the pause and shutdown modes, but this can probably be improved. I also suspect that there need to be some thread locking when handling some of the variables. I hope you can give some feedback on this, safihre or anyone else with a clue.

Re: Optimizing SABnzbd

Posted: June 3rd, 2019, 1:30 am
by safihre
Cool. Let's take this into PR's so we can discuss the code in more depth.

One thing I learned the hard way: what works on a normal Windows PC will work very differently on a ARM NAS for example.
Network and CPU-cycle behavior is not what you'd expect.