Maybe it was because my article last night was somewhat provocative:
The article was published at 22:19:
The attack started around 1:30 and continued until past 10:00 when I was writing the article:
As of 10:37 AM on the 11th, the data is as follows:
Actually, I was still under pressure. On the main site where Docker WordPress is located, the CPU utilization of the base model M1 MacMini reached a maximum of 623% (8 cores total 800%):
Inbound and outbound traffic statistics of the load balancer interface:
CPU utilization statistics:
Note: I wronged Chaitin WAF. I had whitelisted the IP address of the host where the Cloudflare Tunnel is located. After removing it, Chaitin WAF worked very well.
Looking at the statistics on Uptime:
During the sustained attack, it still had an impact on health check packets, which is understandable. However, when I accessed the blog and replied to comments during the attack, everything was normal, though sometimes I might need to refresh the page.
However, I made some changes to the topology later and still did not adopt the method of limiting concurrency on the Baota panel, but instead changed to directly limiting the maximum number of connections on the WordPress port on the load balancer, which allows for deploying one less point.
Overall, yesterday's modification was a success. However, the only drawback is that the free statistical charts in the Zevenet Community Edition are still too few, with too little to look at. I can only say it's better than Nginx...
Since the stress testing is over, to the brother who is attacking, that's about enough, right? Keeping this up continuously is not a solution, I'm getting annoyed by Cloudflare's email notifications...