04:51:47 Fusl arkiver Request to blacklist the following domain returning thoughts of Server returned 0 (CONERROR) 04:51:49 "https://olesadebonesvalls.eadministracio.cat/*" 04:54:59 "https://www.inakiecheverria.com/*" 04:59:34 Got a few million dead link hits for those domains *throws fist up* 05:35:46 looking into it 05:36:08 ah! 05:36:14 yeah we're not going to block those domains but some pattern they have 05:39:28 thanks datechnoman ) 05:39:30 :) 06:45:43 Thanks arkiver! All good. Whatever makes it more efficient :) 06:46:08 yeah in general I try to avoid filtering an entire domain 06:46:35 Also on a side note how did you and JAA_ go with the wget tweak to reduce cpu consumption with an increase to the ram buffer? 06:46:38 there is usually some reason the URLs of that domain are problematic, and that should be fixed (so that it is fixed for all other domains it could appear on as well) 06:46:48 nothing yet 06:47:15 i am not home right now... and forgot to bring the the Wget-AT with FTP updates 06:47:37 in a week I'll be home again, push the FTP code out and after that we'll get an update in for increased buffers 06:54:32 Excellent thanks for the fix then! 06:54:56 Thanks for the update on the code updates also. Will standby till next week :) 06:57:08 let's see how well it works! 06:57:24 might ask you to try out some versions and see if it makes any difference for your setup 06:57:31 (either positive or negative difference) 06:57:49 imagine CPU not being the bottleneck anymore... 07:03:07 Well my dedicated servers have lots of free RAM so that is great :D 07:03:21 CPU has been the killer for quite a long time 07:04:39 bandwidth is never the problem? 07:06:46 nope not even close. Averaging 200mbps/300mbps in/out at peak which is nothing for dedicated 1Gbps links. 07:06:54 nice 07:06:55 CPU just sits at 95%+ the whole time 07:07:07 yeah let's focus on CPU usage improvements over the coming time 07:07:19 I think that'll be the next big set of updates for Wget-AT (after FTP) 07:07:31 Bandwidth and RAM is a hell of a lot cheaper with plenty of overhead 07:07:40 Sounds like a plan. That would be great. Would make it much more efficient 07:08:24 other bottlenecks might be in compression (zstd or gz) and hashing (sha1), so we'll see 07:08:50 but we're not reading the files multiple times with 8K buffers, if we take those out it should already be a big improvement 07:09:31 Baby steps is fine. Dont want to make the code worse or less efficient 07:09:37 no point going backwards! 07:11:57 yes! 07:12:02 we won't be going backwards :P 07:12:13 at some point will want to look into HTTP2 stuff 07:14:09 Sounds like a plan. How does the code handle HTTP2 as it stands? Can it still process it or just skip over it? 07:15:26 not supported 07:15:30 at all 07:19:11 roger. Just threw in some cloud compute to chew through the backlog 07:19:18 Not that we have had much backlog for the past few weeks 07:19:30 been quiet! 07:20:17 been stable :P 07:21:42 joys of dedicated servers on the project to keep a baseline 07:21:59 Mind you we were doing bulk imports a month or so ago with massive lists and stuff of URL's 07:22:13 but you cant complain about things being stable! 07:22:28 we might queue some more large lists again some time soon 07:22:51 will let you all know when that is queued 07:23:32 Cheers ping me anytime 07:23:47 Processing 100,000 URL's a minute at the moment lol 07:23:57 With 4 servers 07:24:10 onlyfiles coming up in a little bit too 07:25:43 Keen! I will be online for another 4 or so hours. So if I can atleast pull the docker container and get it prepped it will start processing when the tracker starts allowing ID's 07:26:06 Plently of spare bandwidth atleast. Will just come down to having a target 07:26:14 right the container 07:26:47 pinged in -bs for building that 07:27:57 Cheers :) 07:28:17 1 day 5 hours. Hopefully enough time! 07:29:45 should be fine if they can hold up 07:29:58 Always the challenge!