Update README.md

This commit is contained in:
SubleXBle
2025-08-25 17:50:09 +02:00
committed by GitHub
parent f5070eceb7
commit 7c10bbccef

101
README.md
View File

@@ -164,32 +164,6 @@ It provides optional tools to:
---
### ⚠️ Upgrade Notice
If you're upgrading from an existing installation
> here will be added some new stuff
---
## 👥 Discussions
> If you want to join the conversation or have questions or ideas, visit the 💬 [Discussions page](https://github.com/SubleXBle/Fail2Ban-Report/discussions).
---
## 📄 Changelog
Details about all new features, improvements, and changed files can be found in the [Changelog](changelog.md).
This is especially useful if you want to manually patch or update individual files.
---
## 🪳 Bugfixes (History)
> - Found a bug? → [Open an issue](https://github.com/SubleXBle/Fail2Ban-Report/issues)
@@ -212,6 +186,50 @@ This is especially useful if you want to manually patch or update individual fil
---
## 👥 Discussions
> If you want to join the conversation or have questions or ideas, visit the 💬 [Discussions page](https://github.com/SubleXBle/Fail2Ban-Report/discussions).
---
## 📄 Changelog
Details about all new features, improvements, and changed files can be found in the [Changelog](changelog.md).
This is especially useful if you want to manually patch or update individual files.
---
⚡ Performance & Stress Test
Fail2Ban-Report has been tested under high-load conditions to verify stability, responsiveness, and reliable synchronization across multiple servers.
Real Scenario:
Duration: ~10 minutes
Webserver events: ~13,400 entries across several jails (mostly SSH)
Data per event: date, action, marker, IP, jail
Key Results:
The WebUI loads all 13,480 daily JSON entries in about 1.5 seconds.
Since each ban is triggered after 4 failed attempts, the actual number of incoming requests corresponds to roughly 53,600 login attempts over 10 minutes → about 5,360 requests per minute (≈ 89 requests per second).
Connected clients consistently pulled and pushed blocklists without any delay. Even when a blocklist update included 80+ new IP entries, the synchronization completed in a blink of an eye, with changes applied in both directions instantly.
Switching between multiple servers in the dashboard remains smooth, typically under 2 seconds, even during attacks.
Takeaway:
Fail2Ban-Report maintains fast performance and reliable data synchronization, proving its suitability for multi-server setups and high-frequency event environments.
---
## 🖼️ Screenshots
![screenshots/Header-050-1.png](screenshots/Header-050-1.png)
@@ -246,37 +264,6 @@ New Feature : Block and Unblock Actions only for logged in admin role
---
⚡ Performance & Stress Test
Fail2Ban-Report has been tested under high-load conditions to verify stability, responsiveness, and reliable synchronization across multiple servers.
Real Scenario:
Duration: ~10 minutes
Webserver events: ~13,400 entries across several jails (mostly SSH)
Data per event: date, action, marker, IP, jail
Key Results:
The WebUI loads all 13,480 daily JSON entries in about 1.5 seconds.
Since each ban is triggered after 4 failed attempts, the actual number of incoming requests corresponds to roughly 53,600 login attempts over 10 minutes → about 5,360 requests per minute (≈ 89 requests per second).
Connected clients consistently pulled and pushed blocklists without any delay. Even when a blocklist update included 80+ new IP entries, the synchronization completed in a blink of an eye, with changes applied in both directions instantly.
Switching between multiple servers in the dashboard remains smooth, typically under 2 seconds, even during attacks.
Takeaway:
Fail2Ban-Report maintains fast performance and reliable data synchronization, proving its suitability for multi-server setups and high-frequency event environments.
---
## 🛣️ Roadmap or "Things I will have to do - but I do them later"
> I gave up the usual Roadmap - to have more freedom with development - Things like Multiserver was never on the Roadmap but allways in my mind.