Issues with the forum

[eto]

Those are client side threads, not server side. If data is being served up slowly a single browser thread can easily keep up, if data is coming down at a more normal rate then the browser will spin up more threads to process it all.

ah okay. I just remembered that many years ago, when I worked for a newspaper, they had a lot of trouble with their website, until they recognized they had a too low limit of max. threads - which resulted in timeouts. I wasn't aware that the browser falls back to single threaded downloading, when the website is generally slow. Is that documented somewhere? I couldn't find it with a quick search.

[Gryzor]

So, question for those who are familiar with htaccess files:

I have added the following:

Code Select Expand

Require not ip 47.128.0.0/16
because we have tons of connections from those IPs (Singapore). Yet, the connections are still there... Am I missing something? (Yes of course I restarted Apache).

I just checked my IP ( https://www.myip.com/ ) and it wasn't me!

Seriously, this could be some kind of attack. Sometimes they use other computers, so this is why I checked. Someone in my family inadvertedly added the computer to a bot network of China to launch cyberattacks or something just because SOPcast or a similar program was installed to watch football.

I also googled the IP you pasted and indeed, it seems some kind of bot attack called Bytespider:

from r/flask

https://www.reddit.com/r/flask/comments/161fqml/what_to_do_about_bytespider/

Yeah, that's a bad crawler alright. I did search for that range but didn't find the thread you mentioned on Reddit-thanks! 

[Gryzor]

So, question for those who are familiar with htaccess files:

I have added the following:

Code Select Expand

Require not ip 47.128.0.0/16
because we have tons of connections from those IPs (Singapore). Yet, the connections are still there... Am I missing something? (Yes of course I restarted Apache).

I'm guessing; if you are filtering at app level (Apache), the operating system still accepts the request.

You may need to use iptables instead to drop those connections.

True and true. But, blocking it at the app level is easier to do and maintain, and it seems that the last update I did was enough to mitigate the problem, so it's ok to serve them cake at the Apache level.

And indeed, the next step is to add the netmask to iptables, but I'm trying to figure out why .htaccess is failing -very weird! 

[andycadley]

Those are client side threads, not server side. If data is being served up slowly a single browser thread can easily keep up, if data is coming down at a more normal rate then the browser will spin up more threads to process it all.

ah okay. I just remembered that many years ago, when I worked for a newspaper, they had a lot of trouble with their website, until they recognized they had a too low limit of max. threads - which resulted in timeouts. I wasn't aware that the browser falls back to single threaded downloading, when the website is generally slow. Is that documented somewhere? I couldn't find it with a quick search.

Well probably in the Chromium source code somewhere. But it'll almost certainly be using a thread pool and the typical behaviour of a thread pool is to only spin up new threads under sufficient load (you don't want new threads for every task).

A problem with a max threads setting is more likely to be a server side issue, where it's artificially capping the number of threads. It's the kind of thing common when the server configuration has been left at something that defaults to a sensible value for a shared user system rather than what's sensible for a box dedicated to a single job (Linux's max open files is one I see come up a lot).

[Maniac]

Much improved and consistent performance for me now. Fingers crossed 🤞🏻 it stays this way. Thanks @Gryzor!

[Gryzor]

Well, seems like things are fast and stable now, at least for me. Anyone else?

Thanks to @eto for prompting me to research connections

[eto]

indeed, since those changes yesterday, I haven't seen any further issues. Thanks for looking into it

[ComSoft6128]

Fine here

[Gryzor]

Just had a time out, but then it loaded as fast as ever. 

[trocoloco]

yesterday it took me a lot checking messages. Today all good here, very responsive

[mahlemiut]

So far, so good.

[GUNHED]

3rd day in a row without problems. The time before made it nearly unusable. Hope it will last as well as it is now. 

[Gryzor]

3rd day in a row without problems. The time before made it nearly unusable. Hope it will last as well as it is now. 

Same here😁

[SyX]

Thanks @Gryzor for fixing all my brazillian problems!!!

... in case that you need to block this region again, because all those stupid banana hackers,  then I will try to use a proxy/vpn. But let me say again, Efcharistó Polí!

[Gryzor]

Thanks @Gryzor for fixing all my brazillian problems!!!

... in case that you need to block this region again, because all those stupid banana hackers,  then I will try to use a proxy/vpn. But let me say again, Efcharistó Polí!

Not a problem, thanks for your patience and apologies for the blanket block! Won't be doing it at such scale again unless something really serious happens, I just had to act fast because I couldn't wait to pinpoint the issue