Entries Tagged 'Performance' ↓
August 1st, 2011 — 3rd Party Integration, Access Control, Admin, Database, Performance, Plugins, Setup, Strategy, Troubleshooting, Web Hosting
Using a “cache” plugin for speeding up your site is like putting band-aid on a gaping wound. It’s only a temporary fix, and not a real long-term solution.
Plus a cache plugin has its place, but it’s certainly not for a membership site, where DAP will need to make calls to the database to figure out who’s viewing the content, are they a member, what products have they purchased, what content do they have access to, etc.
If you want to speed up your web site, you must address the core issue, which is — your web site is getting more traffic than your web server (web hosting account) can handle.
So here are a couple of ways in which you can speed up your web site:
- The easiest thing you can do is to revisit all of your plugins that you have enabled and see if you still need all of them. Remember that every single additional plugin running on your site, adds some overhead to (basically, “slows down”) your web site or blog. So use only as few plugins as you absolutely must. With so many cool plugins freely available for WordPress, it is very easy to get carried away, and install tens of plugins, most of them adding very little value, but sometimes causing the most overhead in terms of server resources. So keep only a bare minimum of other plugins (some social plugins are a real pain – making calls to third-party web sites to get their information from).
- Make sure you are always using the latest version of WordPress, or at worst, one version behind the very latest and greatest (you definitely want to be sure first that there are no conflicts with other critical plugins that you’re using on your site, like DAP).
- Make sure you update all of the plugins you’re using to their individual latest versions.
- If you are hosting on a shared (a.k.a “cheap”) web host paying just a few dollars a month for hosting, then your web site is basically competing for server resources (like memory and bandwidth and database access) with possibly tens (or even hundreds) of other web sites on that same server (many may not belong to you, but to others with whom you are sharing the server – and hence the name “shared hosting”).Search for the keywords “digg effect” or “slashdot effect” on Google, and you’ll see how many WordPress sites crash when a link to the site appears among the top results in popular social sites like Digg.com, Reddit.com or Slashdot.com.If your traffic levels have outgrown your server, then the best thing you can do is to upgrade to a bigger server, or get a Virtual Private Server, or even get a dedicated host, depending on your budget. See our recommended web hosts list.
May 19th, 2011 — 3rd Party Integration, Access Control, Database, Errors, Fail, Performance, Plugins, Protecting Content, Protection FAQ, Setup, Troubleshooting, WordPress Plugins
If you’re having weird issues – like members logging in and seeing other people’s profile information, or logging in as a valid user and being told “Sorry, you don’t have access to this content” – then the culprit almost always is some kind of a “cache” plugin.
Do not use cache plugins on your membership site. If you wish to know why, then skip the section below and go to “Why Doesn’t It Work?”
To fix the issue, keep reading…
Solution To Caching Issues
First, let’s address how to fix your issue if you did have a cache plugin – like WP Super Cache – turned on, and are now having a bunch of login issues with logins and users and access and all sorts of things getting mixed up.
- De-activate the plugin
- Open your wp-config.php file. If there are lines in there that look like this…
define(‘WP_CACHE’, true); //Added by WP-Cache Manager
define( ‘WPCACHEHOME’, ‘/home/xyz/public_html/yoursite.com/wp-content/plugins/wp-super-cache/’ ); //Added by WP-Cache ManagerThen comment out both lines, by adding a “//” at the beginning of each line, like this.
//define(‘WP_CACHE’, true); //Added by WP-Cache Manager
//define( ‘WPCACHEHOME’, ‘/home/xyz/public_html/yoursite.com/wp-content/plugins/wp-super-cache/’ ); //Added by WP-Cache Manager
- Go to your wp-content/plugins/ folder. See if there’s a folder in there called “cache”. If yes, then rename it to “_cache”.
That should do the trick. Now re-test whatever the issue was before, and it would have probably been resolved now.
Why Doesn’t It Work?
Cache plugins are built on the premise that they will “cache” (save and store the contents of) WordPress pages and posts – which usually don’t change for “non-membership” type regular blogs – in a easy to retrieve, static file, so that WordPress doesn’t have to go to the database to load the contents of the page or post each and every time, which will improve the performance and loading time of your WordPress blog in general.
But the fact that such plugins are actually designed to “skip” interactions with the database as much as possible, and will make a “static copy” of your page or post and serve the same static copy to all visitors regardless of who they are, completely goes against the concept of a membership site.
The idea behind using a membership plugin like DAP, it to make sure that different visitors see different content: For ex.,
1) Casual visitors (Non-Members) who have NOT yet signed up for your products, should see content differently than …
2) Members who may have purchased one of your products, but not the product that gives them access to a specific page or post, who should see content differently than…
3) Members who actually have purchased the right product and DO have access to the content, who should see content differently than…
4) Ex-Members who signed up for your subscription-based content in the past, but have since canceled or allowed their access to expire
So, DAP tries to figure out who the visitor is first, and then packages the very same content differently to each category of visitors.
And installing a “cache” plugin kind of makes the whole point of a membership plugin meaningless. Both plugins basically contradict each other in what they’re trying to do.
One (your cache plugin) is trying to speed things up by not going to the database every time, while the other wants to make sure all of the right settings are loaded from the database to make sure your content stays secure from un-authorized access.
So, while cache plugins may work for the average, non-membership, static blog where a single post or page is not really meant to be shown differently to different people, it’s not a good idea to use it on a membership-site.
August 16th, 2010 — Access Control, Amazon S3, Performance, Plugins, S3MediaVault.com, Setup, Video, Web Hosting, WordPress Plugins
Q: Can DAP protect content stored on an external site, like Amazon S3?
A: Not directly, not by itself. By default, DAP can only protect files (and any other content) that is on the same web site where DAP is also installed. For large files, we do recommend that you store files on a fast, scalable file server like Amazon S3. Now, the page or post itself (in which you post that Amazon S3 link) can be protected by DAP, and no un-authorized user can even see the content of the page (or the link within that page).
However, once a user has authorized access to a page because they’re a member, now they can see the page where you have that Amazon S3 link.
It’s similar to posting a public YouTube video on a protected DAP page on your web site. Sure, DAP can protect the page from un-authorized users, but authorized users can actually see the page, and see that it’s a YouTube video, and clicking on that video will directly take them to a page on YouTube.com, which DAP has no control over, and cannot protect once they leave your web site.
Similarly, DAP cannot directly protect that external link to your file stored on Amazon S3. And that’s where our Amazon S3 plugin S3MediaVault.com (S3MV) comes into the picture.
S3MV can make sure that your files on Amazon S3 cannot be accessed directly by anyone, even if the link were shared with others via email or on a forum, and can ONLY be accessed through a page or post on your web site (web site where you have installed the S3MV WordPress plugin).
NOTE: The S3MV plugin is included for free with your purchase of any DAP license, starting with the Unlimited-site license and above.
Q: What’s the difference between storing files on Amazon S3 (and serving it using the S3MediaVault.com plugin), compared to storing the files right on your own web site and having DAP serve them directly to your members?
A: If all files are stored right on your web site, and you have a large amount of video, audio and other files, then a lot of people viewing and downloading them from your site will use up a lot of resources on your server – like site loading time, server memory, server bandwidth, etc – and your site could slow down considerably. Plus, on top of that, there are also bandwidth charges that your host will charge you with for all of those downloads, which are usually not very cheap.
And don’t put too much faith in your web host’s “Unlimited Bandwidth” clause, because if you read the fine-print carefully, you’ll see that as per their TOS, if you consume large amounts of bandwidth and use too much of the server resources, this could cause other web sites (belonging to others) on the same server to slow down and have a degrade in performance. And they could consider this abuse of their TOS, and could either slap you with huge bandwidth or server utilization fees, or may even ask you to take your web site elsewhere because you’re causing issues for other site owners on the same server.
Instead, if the files are stored on Amazon S3, then you don’t have to worry about your site slowing down, or you using up too much bandwidth and getting slapped with huge bandwidth fees, because the files are being served from Amazon’s huge S3 servers which have tons more resources and speed compared to your web host.
Plus in the long run, bandwidth is cheaper on S3 compared to your web host.