Impact on performance/speed?

Hi @dade88 , thanks for your message.

The aim of this plugin is to protect your website for every incoming request. So “yes”, it will look for a CrowdSec decision associated with the current IP and act accordingly for each request: ban, captcha or nothing.

To minimize the impact of this plugin on your speed and performance, it’s best to opt for streaming mode: decisions are retrieved asynchronously with this mode (instead of calling the local API for each request in “live” mode).

But even in this mode, the plugin will take some time to :

• retrieve the plugin parameters
• look in the cache to see if there’s a decision
• display a ban/captcha wall if there’s a ban or captcha decision (if there’s no decision, this step won’t “do anything” and won’t cost time)

I don’t recall a resource with profiling showing how much it costs in terms of speed and performance.

As a subjective reassurance, this plugin uses the Symfony Cache component (which is known to be one of the fastest in the PHP world) and I don’t recall anyone complaining about significant performance degradation.

But, like you, I’d prefer objective measurements. As soon as possible, I’ll try to see if I can do profiling and show some useful metrics.

Thanks again.

It’s great to have such a complete and sincere answer, thank you!

From what I can understand about the “every incoming request” part, it will make the check again when the user browse to the next page. If I am right, maybe there should be a “grace period” after the first check in order to reduce stress on the server (I know I am kind of exaggerating, but…) and on the user’s speed.

Probably won’t be the best security approach, but if sensible areas of the site are covered with other security measures (for example, request certificate for wp-admin) we can add the extra layer of CrowdSec without fear of getting legit users out from the site with close to 0 impact.

Doing some tests with CrowdSec implementations meanwhile, great software overall!

Hi @dade88,

thanks for your message.

Indeed, we don’t have such a “grace period”.

In live mode, you can configure some settings to avoid too frequent calls to the Local API: (see Advanced settings “Recheck clean IPs X seconds” and “Recheck bad IPs X seconds”): for a given IP, only the cached decision will be used for a certain period of time, without the need for a call to the local API.

In stream mode, the cache is always the source of truth.

But in all cases, we will always look for a decision (cached or not).

I wonder how we could implement such a grace period to speed up the process:
For me, we should store this grace period for the current IP somewhere (probably in the cache…), and we should compare the grace period with the current time minus the last decision check (stored as well somewhere) : so there will always be a need to do something and consume resources.

Thanks

Security is not my area of expertise, so maybe this could raise more issues than benefits, but wouldn’t cookies be the solution for this?

Kind of: if the user is not in blacklist (or pass the captcha), a temporary cookie is created on user browser, valid for X amount of time. If the cookie is present, the whole process is skipped until the cookie is invalidated. As this is intended for high traffic sites, a nonce could be created every X, so the server only has to ask the browser for the cookie nonce of the given time.

Even for a very short time, this can save up a lot of checks, but I truly don’t know if this is acceptable from a security perspective.

Hi @dade88 ,

Thanks for the “cookie” idea.

I don’t know if checking for the presence of a cookie will really be faster than checking for a cached value.

But if need be, it could be a solution.

In any case, we need to go back to your original question and highlight a few time/performance metrics.

We will try to do that as soon as possible.

Thanks again

That would be great, thanks you!

Hi @dade88,

I’ve done some basic tests using XHPROF as profiler.


Testing condition

I’m testing locally, with a totally fresh installation of WordPress 6.6.1 and no other plugins than the CrowdSec bouncer :This may not represent production conditions at all, but it’s a start.

details: WordPress 6.6.1, PHP 8.1, Stream Mode ON, Debug log OFF

The test is a simple access to the homepage with a clean IP (no associated decision with this IP) and we are watching the main function of the plugin called safelyBounceCurrentIp

Results

I ran several tests with the same conditions, playing with the cache system and, as the results were not significantly different, I’ll just write a few average measurements :

The total execution time of the safelyBounceCurrentIp function is around 5000 μs (micro-seconds). This is between 4 and 5% of PHP’s total execution time (around 120000 μs).

This function is mainly divided in 3 parts:

– loading settings in database with the getDatabaseConfigs function: between 500 and 600 μs

– instantiating the bouncer (mainly init filesystem, redis or memcached cache, init curl or file_get_contents client, and init the bouncer rules depending on various setting) with the CrowdSecWordPressBouncer\Bouncer::__construct function: between 3500 and 4000 μs

– bouncing: retrieve decision (from cache here) and acts accordingly (do nothing here as we test a clean IP) with the CrowdSecBouncer\AbstractBouncer::run function: between 600 and 800 μs

Conclusion

I’m not sure these metrics are fast enough for you: it’s a bit subjective. And it should be consolidated with production tests (to see if those 4/5% increase or decrease with high web traffic and a WordPress site with lots of other plugins).

The second part of the process (instantiating the bouncer) is clearly the slower one. Perhaps, we could find a way to improve this.

Finally, if we see a large number of users complaining about performance degradation, we could work on a way to cut out parts 2 and 3 altogether (with your cookie solution or otherwise).

Feel free to open an issue on our GitHub repository if you want us to work on it.

Thanks again

We are currently testing the implementation, so I would not feel honest asking for a feature of something we may not even use in the near future. But, I am glad you found a possible way to improve the plugin.

As for the data, it seems pretty damn fast! Can’t wait to test it on some sites with decent traffic and security needs.

Congratulations on your detailed answer and this awesome software.

Hi, I’m closing this issue. Happy to continue the conversation here or elsewhere.