Title: Reducing server load
Last modified: August 21, 2016

---

# Reducing server load

 *  Resolved [Mark Barnes](https://wordpress.org/support/users/mark8barnes/)
 * (@mark8barnes)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/)
 * Thanks so much for this plugin. Like many users, one of the problems I have with
   brute force attacks is the server load is killing my server. Glancing through
   BruteProtect’s code, I can see that it works by hooking into `wp_authenticate`
   or `wp_login_failed`. The problem with this approach is that a decent chunk of
   the WordPress framework is already loaded by that point, and it would be nice
   to do any checking as early as possible, and there are several possible options
   you have for doing that at an earlier point.
 * The earliest would be by just adding an `IF` statement in `bruteprotect.php`,
   and not using actions. For example, you could check for the `$pagenow` variable
   or look at the `$_SERVER` variable. If `wp-login.php` was being called, you could
   then run `brute_check_loginability`. The only code you need to add is:
 *     ```
       if (isset($pagenow) && $pagenow == 'wp-login.php')
           brute_check_loginability();
       ```
   
 * On my test server, adding this to the code reduces the length of time the PHP
   process runs for from an average of 166.1ms to just 84.9ms (assuming a cached
   block). If you’re being hit every few seconds, as mine is, that makes quite a
   difference to server load. As it stands, the plugin makes almost no difference
   to server load (unless the bot is intelligent enough to stop trying when it gets
   a 403 error, which judging by my server log, most aren’t).
 * PS – I noticed two bugs:
    1. You’re missing a closing PHP tag in index.php.
    2. Your local IP check ought to have IPv6 compatability, and therefore check for‘::
       1’ in addition to ‘127.0.0.1’. It would also be very slightly more efficient
       to check for this IP before doing get_site_transient(), though server load on
       localhost is never likely to be an issue.
 * [http://wordpress.org/plugins/bruteprotect/](http://wordpress.org/plugins/bruteprotect/)

Viewing 11 replies - 1 through 11 (of 11 total)

 *  Thread Starter [Mark Barnes](https://wordpress.org/support/users/mark8barnes/)
 * (@mark8barnes)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052077)
 * On a similar theme, it would be great if there could be an option for IP addresses
   with very high activity to receive a permanent block in .htaccess, to reduce 
   load almost entirely. Perhaps now that you’re counting attempts over a particular
   period of time, your API could send an additional flag if there’s a two year 
   block on the IP. I presume that the 65 failed attempts is not per-site, but spread
   over your entire userbase?
 *  [rwilki](https://wordpress.org/support/users/rwilki/)
 * (@rwilki)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052250)
 * Mark, thanks for your post. Have you privately heard from them about this? I’m
   considering using this plugin. Where do you suggest using your “IF” statement?
   Have you tried it?
 * Thanks,
    Bob
 *  [David Anderson / Team Updraft](https://wordpress.org/support/users/davidanderson/)
 * (@davidanderson)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052255)
 * > You’re missing a closing PHP tag in index.php.
 * I’m not part of the BruteProtect team, but this isn’t a bug. This is now the 
   coding style preferred in WordPress core – in my opinion, for good reasons (for
   one, it protects you against problems caused by extra whitespace after the close
   tag).
 * David
 *  Thread Starter [Mark Barnes](https://wordpress.org/support/users/mark8barnes/)
 * (@mark8barnes)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052259)
 * > Mark, thanks for your post. Have you privately heard from them about this? 
   > I’m considering using this plugin. Where do you suggest using your “IF” statement?
   > Have you tried it?
 * I haven’t heard anything about my suggestion. If you want to try it, it is easiest
   to add the code at the very end of the file. I’m using the modified code without
   any problems on WordPress 3.6.
 * > I’m not part of the BruteProtect team, but this isn’t a bug. This is now the
   > coding style preferred in WordPress core
 * Thanks for letting me know. I’m obviously behind the times!
 *  [TJGreene](https://wordpress.org/support/users/tjgreene/)
 * (@tjgreene)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052282)
 * It would be good to hear from the developer on this.
 * We are testing BruteProtect to determine if we can recommend it to our blog readers
   and WordPress clients. However, we just experienced a brute force attack on our
   server that brought it to its knees for 3 hours. CPU and other resources were
   being maxed out. BruteProtect showed over 3,000 attempts on just one site during
   that time.
 * The (shared) hosting provider we are testing it on is saying that the server 
   problem is due to BruteProtect and that we’ll either need to fix the issue (remove/
   repair BP) or upgrade to a VPS or dedicated server.
 * Clearly, the problem is with the actual brute force attacks and not a malfunctioning
   plugin. However, if BP can’t somehow mitigate an attack’s deleterious effect 
   on server load, then it won’t be a truly viable tool against BFAs.
 * What say you, Sam?
 * Regards,
 * TJ
 *  Plugin Contributor [Sam Hotchkiss](https://wordpress.org/support/users/samhotchkiss/)
 * (@samhotchkiss)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052288)
 * Hi TJ– this is interesting.
 * So, we have to do a few things:
    1. When someone accesses the login page, check their IP against the BP servers.
       We cache the results in your local DB so that you don’t have to call out every
       time if the user keeps trying. We call this process “checking loginability”
    2. When someone attempts to authenticate, we check their loginability again. This
       allows us to protect against a bot that is directly POSTing login attempts, 
       and to protect sites that are allowing log ins from the front end of the theme,
       among other reasons. Since we’ve cached the BP results, this process normally
       just involves a single DB query
    3. When there is a failed login attempt, report that IP back to the BP servers
 * So, the first time a new IP tries to connect, there is a little bit of overhead
   as the API is pinged. At a maximum, this involved running 9 additional queries,
   and waiting a moment while the remove server is connected to. Once the IP has
   been checked and cached, we’re down to 2 queries and minimal increased load time(
   in the range of a rounding error– in my tests, on average, you’re talking about
   one or two thousandths of a second).
 * That said, it’s worth noting that an out of the box WP install with NO plugins
   installed uses 28 queries to load your homepage.
 * At the end of the day– is there a performance “hit”? Sure– any code you execute
   on your site is going to require resources. Is there a more efficient way to 
   do it? Not that I can devise, although I’ve never proclaimed myself to be the
   smartest guy in any room.
 * However, if your host is really complaining because you’re trying to keep bad
   guys from logging in, then I’d be in the market for a new host. To me, this sounds
   like your host calling you and saying “Hey TJ, You’re getting a lot of spam comments
   and all of those Akismet API calls are slowing our servers down, can you just
   turn off Akismet and let your site fill up with spam?”
 * Mark– I like your $pagenow approach for our initial loginability check, as opposed
   to login_head. I’ll be testing that and, if there are no issues, including it
   in our 1.0 release, which is slated for early October with lots of cool stuff
   in the pipeline!
 *  Thread Starter [Mark Barnes](https://wordpress.org/support/users/mark8barnes/)
 * (@mark8barnes)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052293)
 * [@sam](https://wordpress.org/support/users/sam/)
 * I’m not sure you’ve fully understood the initial question/concern. We’re not 
   really concerned that BruteProtect **adds additional server load **through extra
   queries and http calls. That’s inevitable if it’s going to do it’s job. But we’re
   much more concerned that BruteProtect **doesn’t reduce server load** by preventing
   the WordPress framework from loading every time `wp-login.php` is requested.
 * Our servers can’t afford to process `wp-login.php` if the server is being hit
   multiple times per second. **Currently, BruteProtect does a great job of preventing
   attackers from gaining access to the site, but it does a lousy job of preventing
   attackers from bringing the site down**. We need a way of blocking attackers,
   without loading the whole WordPress framework. Blocking IP addresses through `.
   htaccess` is one method, but it doesn’t really work with distributed attacks.
   The `$pagenow` method I suggest is another way, which halves the problem, but
   doesn’t eliminate it.
 * But the most important point is that the earlier you can block the attack, the
   less server resources are used, and the more useful the plugin will be.
 * The ideal solution for me would be to modify `.htaccess` so that wp-login.php
   actually ran a standalone version of BruteProtect, rather than the real `wp-login.
   php` page (by ‘standalone’, I mean a version that has no WordPress dependencies).
   If there was no attack, the real `wp-login.php` file would be served (perhaps
   by redirection, or by simply requiring the file). If there was an attack it would
   be blocked, without any of the WordPress framework ever loading. The only server
   load would be BruteProtect itself, which should be pretty minimal.
 *  Plugin Contributor [Sam Hotchkiss](https://wordpress.org/support/users/samhotchkiss/)
 * (@samhotchkiss)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052294)
 * Hey Mark– thanks for your feedback here.
 * This would introduce a number of potential complexities for wide distribution,
   not the least of which would be getting DB access. If we include `wp-config.php`,
   it then loads `wp-settings.php`, which then loads the rest of core. So this standalone
   script would have to include your DB credentials.
 * The `$pagenow` method seems like a good solution that would “just work”.
 * We could also potentially store an array of blocked IPs in a file, negating the
   DB access issue, although I’m not sure what the read/write tax would be.
 * We’re working with a hosting provider right now on helping them develop and implement
   a low-level brute force attack prevention system. Hopefully this will develop
   into something that will be widely applicable.
 * I really appreciate your feedback here, Mark, and we’re open to any further thoughts
   you might have!
 * Best,
    Sam
 *  [TJGreene](https://wordpress.org/support/users/tjgreene/)
 * (@tjgreene)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052295)
 * Hi Sam,
 * I agree that we received an unacceptable response from our web host. When we 
   went up the chain of command the tone changed and they acknowledged the BFA, 
   saying server logs showed, “approximately 20,000 hits between 1pm and 5pm”. FWIW,
   BP showed it blocked 3,256 malicious attempts during that time.
 * However, [@mark](https://wordpress.org/support/users/mark/) is correct, it’s 
   not the plugin’s effect on server load that is our concern, but, that it doesn’t
   help to prevent a BFA from overloading the server. Being able to block attackers,
   as [@mark](https://wordpress.org/support/users/mark/) describes, is what would
   make BP a standout product.
 * I know you are working on a lot of enhancements to BP and I appreciate your dedication
   to making it better. I am looking forward to testing future updates as BP continues
   to evolve.
 * Regards,
    TJ
 *  Thread Starter [Mark Barnes](https://wordpress.org/support/users/mark8barnes/)
 * (@mark8barnes)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052296)
 * > I really appreciate your feedback here, Mark, and we’re open to any further
   > thoughts you might have!
 * On reflection, I do have a further thought, which I think would certainly help:
    1. Create a cron job to cache the blank wp-login.php form as a static html file.
    2. Before writing the static html file, change the form’s action to a random address(
       e.g. [http://www.mysite.com/wp-login-a7f45f3b4.php](http://www.mysite.com/wp-login-a7f45f3b4.php))
    3. Add a WordPress action to intercept requests for the random address, and tells
       WordPress to handle it as a proper login, using BruteProtect’s existing API.
    4. Modify .htaccess so that requests for wp-login.php are redirected to the static.
       html file
 * Using this method (or something similar), you should significantly reduce server
   load, as for almost all brute force attempts you’d only be serving static files
   rather than PHP files.
 *  Plugin Contributor [Sam Hotchkiss](https://wordpress.org/support/users/samhotchkiss/)
 * (@samhotchkiss)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052303)
 * Hey Mark– I’m going to keep working on this, but I wanted to let you know that
   I did just release version 0.9.9 which includes your `$pagenow` mod
 * Best,
    Sam

Viewing 11 replies - 1 through 11 (of 11 total)

The topic ‘Reducing server load’ is closed to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/bruteprotect_372a22.svg)
 * [BruteProtect](https://wordpress.org/plugins/bruteprotect/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/bruteprotect/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/bruteprotect/)
 * [Active Topics](https://wordpress.org/support/plugin/bruteprotect/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/bruteprotect/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/bruteprotect/reviews/)

 * 11 replies
 * 5 participants
 * Last reply from: [Sam Hotchkiss](https://wordpress.org/support/users/samhotchkiss/)
 * Last activity: [12 years, 9 months ago](https://wordpress.org/support/topic/reducing-server-load-1/#post-4052303)
 * Status: resolved