Warning: Serious Performance Hit

Hi @megaz,

Correct. This is true of ALL front-end-loading plugins, but especially anti-virus/anti-spam/security/firewall ones. This is expected, not an aberrant behavior.

All front-end-loading plugins are going to use up server resources, but spam/security plugins, which are running your site visitors through multiple checks, are definitely going to have a more noticeable impact, especially those who are on shared hosts or otherwise low quality hosting environments.

Granted, with the right amount of time, money, and expertise, if the plugin was completely rewritten from the ground up, of course we could improve performance and require less memory, but it’s very important to understand the limitations of the project.

Until only recently, the project has been entirely free and open source for many years. We’ve begun to try and help fund the project through donations and by offering a Premium version, but only time will tell if that will be enough to allow us to make such massive overhauls.

I run Stop Spammers on all of my own sites and client sites in many varieties of hosting environments; it’s never caused such a detrimental performance hit to justify its removal. Of course, I also optimize for speed aggressively in many ways.

I also implement many other layers of security and spam filters. If we want to really get into the weeds, the ultimate goal is to eventually beat out the resource issues caused by spammers, with the resources required to stop them. In some cases, you’ll actually see a spike in performance in the beginning, but after time, after you’ve blocked enough bad behavior and enough IPs, it levels out to where you’re saving resources.

Of course, every website is different and it’s absolutely possible that you might lose more performance from fighting spam than just leaving it alone. A perfect example would be a non-membership website with low traffic. Your spam levels and vulnerable attack surface are probably negligible.

In any case, I should probably just turn this into an article and also share some tips about optimizing speed in addition to security, cause this probably well past the point where anyone would want to read this here on these forums.

And, if you actually have any specific suggestions or would like to contribute code improvements, you can do so here:

https://github.com/Trumani/stop-spammers/issues

Thanks ??

@bhadaway, no, this has nothing to do with poor hosting – I have dedicated servers running excellent hardware.

The problem is with your code. I just rolled back to version 2020.3 and the load went back to normal. Your 2020.4 release is very buggy. Run a timed curl between the two and see for yourself…

I am guessing the performance issue has to do with a boatload of disposable emails you’ve added in the 2020.4 branch. It is a giant array, and I am guessing that PHP slows down to crawl when you try to parse through that list.

Test it out in your own environment, compare 2020.3 to .4 and you will see exactly what I mean. My load time more than doubles with the 2020.4.1 branch!

I am guessing the performance issue has to do with a boatload of disposable emails you’ve added in the 2020.4 branch.

This actually crossed my mind, and of course is a factor (everything is), but hosting environment and many other things are of course still important variables too.

Again, I haven’t experienced any performance issues of my own, yet… And again, to be very clear, everyone’s setup is going to be different. I’m not saying that you haven’t experienced slowness since the new update; I believe you.

But, this isn’t an argument or debate; did you actually want to solve the problem, or just tell us the code sucks? If the former, cool, let’s keep working on it, and if the latter, please let me know so I’m not wasting anyone’s time here.

So, the obvious suggestion:

Disable the disposable email check if you think this hurts your site more than it helps it.

But, if you’d like to keep it, but also optimize for speed, some suggestions:

1. Make sure that everything is up-to-date, especially PHP (7.3).

2. I highly recommend WP Rocket as your caching solution.

3. I also recommend integrating Cloudflare (a free account is fine).

4. Even more spam protection, but at the server level. Anything Jeff Starr (@specialk) releases is pretty awesome:

https://perishablepress.com/tag/blacklist/

Specifically, this honeypot is super effective:

https://perishablepress.com/blackhole-bad-bots/

But even on WordPress, I recommend using the stand-alone version over the plugin.

Again, I’m not dismissing what you’ve reported here, but I need to wait and see if enough people experience problems with it to justify its removal.

Thanks

@bhadaway, I am not here to waste anyone’s time. I like your plugin, and it is the only plugin that actually works to prevent spam, especially for busy sites like mine.

Hosting makes a difference, but in my case, I am running 5 servers in a load-balanced environment, with Cloudflare in the front. When measuring the performance of your plugin, I am running it without any caching in front, simply measuring back-end performance. The latest update is certainly creating a huge performance bottleneck, and I can easily tell the difference between 2020.3 and 2020.4. I tried disabling the disposable email check option, but it is not doing any good – I believe the performance issue is stemming from too large of an array.

I looked at the code differences between 2020.4 and 2020.3 – it looks like the large array is the biggest change you’ve implemented.

I am surprised you are not seeing any performance issues. Have you tried to time page load time with 2020.3 vs 2020.4?

Please don’t take any of this as a criticism of your work. This is a great plugin, and I hope you succeed with your efforts with monetization.

There’s nothing wrong with criticism. However, it’s rare to receive any constructive criticism. Usually it’s just a way for people to vent on their way out:

https://www.ads-software.com/support/plugin/stop-spammer-registrations-plugin/reviews/?filter=1

Some people just want to complain and don’t actually want any assistance, which is okay, but if I’m going to spend my time wisely, it should be helping those who actually want help. Thanks for clarifying.

Okay, I was misunderstanding you. I was speaking in terms of overall site performance, and you’re speaking in terms of strictly the raw performance of the plugin. Gotcha.

Yes, certainly, as we continue adding new spam checks and beef up the spam checks that already exist, the plugin load is gonna be heavier. I’m a minimalist and NOT a fan of bloat. I did not create this plugin (I was originally just a user myself). When I code something from scratch, my goal is to accomplish something with as few lines of code as possible.

That said, have we gone too far? Maybe. Maybe we’ve reached the limit of what we can cram into one plugin. That’s going to be a tough discussion, and we’re probably going to need help from the community.

For example, maybe some checks are obsolete and we could cut some fat?

These forums aren’t ideal to track an issue like this, so I’ve created a GitHub issue here:

https://github.com/Trumani/stop-spammers/issues/156

You’ve actually made me aware of a much larger, systemic issue that will need to be addressed going forward. We’ll definitely keep an eye on this and discuss options.

Thank you.

Thanks @bhadaway for understanding.

I don’t think the issue in this particular case has to do with bloating – could be simply something PHP is having a hard time parsing, so it is creating a much bigger load on the PHP server and reducing page load time. I am running HUGE plugins like WooCommerce, which have hundreds of PHP scripts with a boatload of content – none of them slow down the site. So you have a long way to go before this plugin becomes bloated. I simply think the changes implemented in 2020.4 are not good in terms of performance impact. Once again, if you simply put the 2020.3 code against .4, you will see that the script execution time has increased dramatically.

For a start, I would recommend rolling back the changes from 2020.4 to 2020.3, which should address the performance issue immediately. Then we can see what can be done with parsing of thousands of domains through an array – perhaps there is a more efficient way to do it.

Please keep in mind that whoever updates to the 2020.4 version is already impacted – rolling back or pushing a 2020.5 update that removes the performance bottlenecks is going to make both website owners and hosting companies happy ??

Thanks for the hard work!

@bhadaway, after a little bit of troubleshooting to find out what was wrong, I found the issue. The problem is not with the giant array of files in the chkdisp.php, that’s not what is halting PHP. The problem is with the main stop-spammer-registrations-new.php script. Specifically, here is the line of code that is doubling PHP load time for me:

add_filter( 'gettext', 'ss_login_text' );
function ss_login_text( $translating ) {
        $options = ss_get_options();
        if ( isset( $options['login_type'] ) && $options['login_type'] == "username" ) {
                return str_ireplace( 'Username or Email Address', 'Username', $translating );
        } else if ( isset( $options['login_type'] ) && $options['login_type'] == "email" ) {
                return str_ireplace( 'Username or Email Address', 'Email Address', $translating );
        } else {
                return $translating;
        }
}

As soon as I stop add_filter( ‘gettext’, ‘ss_login_text’ ); from calling the ss_login_text function, performance comes back to normal.

Here is the timed curl response time before and after:
real 0m0.750s
real 0m0.766s

After:
real 0m0.329s
real 0m0.336s

As you can see, that one line of code is causing the script execution time to more than double.

It looks like you are not using gettext correctly, which is causing all the performance issues. Please have a look at this article for more details on what gettext can do on busy servers:

https://pippinsplugins.com/dangers-gettext-filter/

The specific line in your code that is wreaking havoc is “$options = ss_get_options();” – I suspect it is somehow invoking all options to be translated? Who knows, but the issue has been identified, and I suggest that you remedy it as soon as possible and avoid gettext calls altogether, if possible.

I went through every plugin I have, and not a single one invokes gettext. I think this filter is too dangerous and should not be used in a live environment…

Nice find! Investigating now…

Fixed. We’ve removed gettext until we can find a better solution. Please let me know if everything is sorted now.

Amazing, thanks Bryan!!! Yes, this solves the issue completely.

You’re welcome.