Best Practice for Caching

Hello,

I have quite stable EE setup more than 1 year at small Linode VPS. I have been using Nginx cache (–wpfc) with all my sites since beginning. But my hosted site amount getting increase every day. (Mostly very low traffic)

I wondering to know If I’m using best practice for caching?

My server has 2 GB ram.

What are your opinions?

Try redis with autooptimize plugin. Works great for me.

1 Like

Yes, try redis, it works great. But with 2GB of ram do not use the redis object cache plugin for wordpress. Caused me issues. Had to get a server with a little more ram

How big was that WordPress site? Was it the only one on the server? I have about 7 WordPress installs all with redis/php7 on a 1gig droplet with 1gig swap. These are relatively small sites with low traffic. Couple thousand pageviews a day.

I wonder if it is the swap that keeps my head above water? Because I am running my mail server on the same droplet and have had no issues.

I’m running 7 wordpress sites plus a standalone forum. Roughly i get about 150,000 to 200000 pageviews a day.

I hope your swap usage is zero. If not you need more ram or find out whats using all that ram.

7 wordpress sites on 1gb of ram? It certainly is possible but i can’t see it running well

A customer of mine has 27 WPs in 1GB RAM and everything runs like a charm.

It depends more on your code (theme + plugins) than any other factor.

1 Like

He must be using tons of swap

As I said, everything is working perfectly fine.

Thats great if its all working fine.

I am running 2 site one has 0 page view other is also least pageview. But My server corrupts every week. mysql did not start Can you please share some configuration. I am new to easy engine. setup log rotate, mysql cache tried many ways but nothing works

Nothing special to show; it is just the ordinary EE default configuration.

I really don’t understand what’s going on with your server.

I had something like that happening to my super low traffic site on 1GB ram server. Almost went crazy trying to figure out what was causing DB to fail. Ended up being caused by brute force attacks to wp-login.php, so check your logs, concentrate on POST requests from the same IP and eliminate them. You could blacklist those IP’s or BlackList whole certain countries, I ended up doing a few things. Making log-in screen more secure, adding captcha and finally changing the default directory string so now it’s www.mysite.com/somethingcustom to access login screen. Probably an overkill, but haven’t had an issue in over a year! :slight_smile:

@Kalach, you must be right.

If this is the case, I’d install a plugin like iThemes Security (probably overkill for one single function) or WPS Hide Login. The idea is to move wp-login.php to a secret location.

After that, I’d create a rule in nginx.conf:

location /wp-login.php { deny all; }

That should completely stop anyone from accessing the default script; and if one doesn’t know where is your front door, how could your house be broken?

1 Like

My 2 cents.

If you have fail2ban on the server