I wanted to see how many UDP requests we could handle by hardcoding the "announce" response, eliminating the use of the torrent repository and its locks. This approach allows us to focus solely on the UDP layer's performance.
Surprisingly, the number of requests remained almost unchanged, indicating that the bottleneck likely lies within the UDP layer.
Additionally, it appears that the aquatic UDP load test initiates a new connection for each UDP request, as the numbers of connect and announce requests are similar.
I think I will hardcode the "connect" request, too, to see what happens.
I wanted to see how many UDP requests we could handle by hardcoding the "announce" response, eliminating the use of the torrent repository and its locks. This approach allows us to focus solely on the UDP layer's performance.
Surprisingly, the number of requests remained almost unchanged, indicating that the bottleneck likely lies within the UDP layer.
Additionally, it appears that the aquatic UDP load test initiates a new connection for each UDP request, as the numbers of connect and announce requests are similar.
I think I will hardcode the "connect" request, too, to see what happens.