A few months ago, after regular “try our service – you’ll love it!” calls from the cloud folks over at ixWebHosting, I went ahead and setup a shiny new cloud server. My cloud hosting over at another company – rhymes with “backspace”, well, it just seemed to be draggy loading up sites. It prompted another search for a decent host. Needed some decent horsepower, wanted the uptime of cloud, decent support, and wanted something that I didn’t have to manually go in and configure myself from bare metal since I’m not a Linux/Apache guru. ixWebHosting has a nice cloud setup that met those needs. However, being the victim of my own exuberance over new solutions in the past, I wanted to give it a test for a while to make sure it kept on performing before I committed all my websites to it.
Uh oh. Problems begin…
So 2 months into this, my sites started dragging one afternoon. H*LL. They weren’t even loading – shades of “backspace”. Went into the WHM console – couldn’t even bring THAT up. For the love of God. Reboot from management console – that doesn’t actually run on that server instance. That took a few hours as it didn’t come back up smoothly. ix support got it running again, and then I discovered the “Error connecting to database” page. Hmm… mySQL server hadn’t restarted. Started that and boom. We’re up. Life continues on with me thinking it a one-off problem. Nope.
Sort of like the first time you end up sitting on the side of the road with your car – after that, you just don’t have quite the same trust in it, do you? Noticed that the sites would drag – started watching the WHM console for server usage. It normally cracks at about 0.05% usage. Dual core Xeons and 2 GB of RAM. Hmm.. why is it running 35% usage? And apparently 35% usage is enough to keep this webserver from doing what it’s supposed to be doing very effectively – serving web files – my WordPress sites.
Go on for another few days with some lagginess, but nothing atrocious. Then a client demo – and the site bogs during the middle of it. AAAARRRGGH. I contacted ix support again, with “Please help” message. They checked the logs and apparently somewhere in there, my processor usage and memory consumption had gone to 100%. Frick. Reboot again. Okay. There’s a problem – these are WORDPRESS SITES – we’re not talking corporate solutions with tons of backend coding and calls – though nice clean .html files WOULD serve a lot faster… They suggested more memory. I’m not a Linux guy, but resolving the problem by throwing more memory at it just did NOT seem to be the final solution to me.
In computer repair, we have suggested RAM sizes for different operating systems, but a Windows machine running something simple like XP can do all sorts of things with 2 GB of RAM without crashing. Thinking about all the customers that I have dealt with over the years NOT taking my suggested solutions, then coming back to bitch at me because the problem wasn’t resolved… I figured that I’d be best off following their experienced advice. I did throw another 2 GB of RAM at it as per their suggestion. At least I’d have a leg to stand on should the issue crop up again LOL. Besides, no one ever complained about their performance with too MUCH memory.
They also suggested I allocate more memory to the PHP processes. Boosted that up as well from 256m to 320m or so. Things actually went smoothly for a day.
The Problem is NOT the Cloud Server
Protecting Your WordPress Site with Plugins
I might also mention that these days, I normally install WordFence among other plugins. Find it very helpful to keep people from attempting multiple hack attempts and from some various other exploits. But there are limits. And I hadn’t installed it on all of my sites for whatever reason. Went in and installed it on all remaining sites on that server. Lo and behold, the alerts mails started pouring in. A few from various sites here and there, but there was a boatload of them for one small site that I have that really should NOT be getting a lot of hits – and certainly NOT a bunch of login attempts.
I went ahead and got intimate with the WHM interface to take a better look at the actual processes that were running and all that. And sure enough, that specific site was getting hammered. Login attempts one right after another ongoing for hours on end – and it was only getting worse.
Throw another plugin at it – BulletProof Security
I installed the BulletProof security plugin on most of the WordPress websites to help lockup the configs. I’m sure a knowledgeable Linux / Apache admin could have probably whipped something up without a plugin, but it is beyond the scope of MY smarts. Since someone apparently seemed to have taken a shining to this site, there’s no telling what OTHER mischief they were up to and I needed protection NOW. And who knew if they were actually going after that name in particular or just something on THAT IP – and how long before they turned their attention to ANOTHER site on this server? Can’t have my main box going down sporadically – and need to find a solution that I could use on any of my sites.
The one thing I am not enthralled with using BulletProof is that it truly has some geeky code that I have yet to fully grasp. But if it does what it says it’s going to do, I’m all for it. The interface is not real intuitive and it DOES help to watch their little video to figure out what the heck to do to install it. That all said, it still didn’t solve the exact problem. Though it DID give me a warm fuzzy knowing that it was even more thoroughly protecting my WordPress websites from general jackassery.
The problem continues
So… yesterday morning, I get up ready to start on some serious web design and SEO work. And what do I find? An absolute SLEW of failed login attempts from all over the world on this one poor little site. Really? Has someone broadcast an international challenge to hack THIS particular site or what? I’m guessing that a scrapebox run turned up something that is absolutely enticing to these login scripts. Even if it’s a bunch of users or just one geek with a swarm of bots out there, we’ve got ourselves a WordPress brute force attack. Regardless of why they were hitting this site, it was tanking all the other sites on this cloud server and making working on the server a LOT like working on that “Backspace” cloud server – even when it was running its best. Not acceptable.
Didn’t have time to figure this all out. And surely don’t want my customer sites all bogged because of this secondary site getting beat on. Redirected the site to a parking site at GoDaddy to immediately resolve this issue so I could take care of what NEEDED to be taken care of. A little more watching yesterday, and server performance went back to uber-snappy. Proc levels back to 0.05% with all sites being served quickly and efficiently. Love it. Which is why I wanted this new cloud server to begin with.