hub.bugout.link performance

Hi Chris:

I've been building a _tracker server tester_ and as part of that I built my own tracker server. I wanted to share some observations that might help you understand the performance issues you've been experiencing with `hub.bugout.link`.

**Short Summary**
Your tracker server got added to a list of tracker servers that is used widely by users in China who use an app called [BitComet](https://www.bitcomet.com/en). The users in China are very likely killing your server. [This issue](https://github.com/ngosang/trackerslist/issues/257#issuecomment-648742255) was opened by someone to have your tracker server added to [trackerslist](https://github.com/ngosang/trackerslist). You can open an issue to have your server removed, too, per the [trackerslist readme](https://github.com/ngosang/trackerslist).

I know this to be the reason for your server's performance issues by reviewing [https://hub.bugout.link/stats](https://hub.bugout.link/stats) and seeing that it matches my own server's stats after personally requesting my server be added to [trackerslist](https://github.com/ngosang/trackerslist), in particular the type of client showing up in the stats: [BitComet](https://www.bitcomet.com/en).

**Details**
While testing my _tracker server tester_, I found that your server often responds with a `server 400 bad request`. I remember you mentioning that SlingCode introduced extra load to your server, and at the time, that was the explanation for the performance problems.

However, I am starting to see the same kinds of problems with my tracker server, and I don't have any major applications built that uses it yet.

My tracker server was built to run on Heroku since it has a free plan and also a low price plan. After getting things working, I opened an issue with [trackerslist](https://github.com/ngosang/trackerslist) to have my tracker server added to the list -- I was curious to see how it would perform with many users. Once it was added, I noticed that my Heroku server was generating a lot of errors and the response time was averaging 30s(!). I've gotten 3.5 million requests to my server and the majority of them are from China users using BitComet.

Since I am using Cloudflare for the CNAME associated with my domain and the Heroku app link, I was able to identify the origin of the traffic with Cloudflare's web analytics. The majority of traffic was coming from China. So, I added a firewall rule to block all traffic from China. This solved the performance issue for about 24-48 hours or so, bringing the response time of my server back to single digit milliseconds. But today it's getting pegged again despite the firewall rule. I have a case open with Cloudflare support to explain why only ~ some ~ traffic from China is getting blocked and other traffic let through.

In the end, I would like to block certain types of clients, or _only allow_ certain types of clients like WebTorrent. It seems that bittorrent-tracker could allow this, since the stats page lists the connected clients, but it's not clear from the documentation how to do that.

I hope you find this information useful.. 🔢

Thanks,
Dan

Start by reviewing the tracker server behavior, the /stats endpoint, and the bittorrent-tracker documentation referenced in the issue. Determine whether client filtering is supported and clarify whether the intended outcome is documentation, a configuration option, or new filtering behavior. Done should include an agreed scope and a way to verify that unwanted client traffic no longer causes the reported performance problems.

Written by the indexing model from the issue text.