So what happens if I go through that process, and then no error happens?
How will that help me understand the issue?
That will simply tell you that there is something amiss with the infrastructure/setup you have at your aws instance/setup.
I ended up hiring a technician to work on this. Please see this and offer an alternate solution if possible:
"After checking the performance locally, it does not seem to be something wrong with the plugin apart from it being cpu hungry.
What I see happening is a feature of the plugin “Enable image locking features” checkbox takes quite of the processing power. On my local machine with a quad core processor, it loads the page in ~10 seconds.
After disabling the checkbox of that feature, it loads the page normally.
Now I checked the specs of the hosting machine and it also has 4 cores. PHP has a timeout of 60 seconds set for the server. So if 1 user page load is taking ~10 seconds on my machine then 10+ concurrent users on site would cause php timeout for some users because the cpu is already busy processing the existing requests.
So when it is packed with requests, it would be causing the site not to load for some users
this must also be why the developer did not see the problem on dev/clone site because it would not have the extra traffic.
The quick fix for this would be to not use that feature if it is not required. If that is not possible then the only other options are to increase the php time limit which I think might not help for the long term. Or increasing the hardware resources but I will not recommend this because a plugin should not be using that much of processing power."
I definitely need that feature on. And can’t have the page loading time be 10 sec+.
That’s a more useful lead indeed.
Now, indeed the image locking feature is resource-consuming. It redirects all requests to Apache to PHP to decide if the image should be locked, and if it should, it obscures the image.
For already cached obscured images it should not be so much resource consuming, but the developer may not have been able to test it, thats ok. It also depends on the size of the image naturally - the bigger the image, the longer it will take to generate cached locked images.
…
As for solution:
If you need an advanced feature like image locking feature, you need to get a hosting package from somewhere with can handle it. There are no two ways about it. There is nothing we can code into the plugin on our side which can circumvent technical limitations of modern hardware infrastructure.
My recommendation:
Get a cheap simple Linux shared hosting account in a place like Godaddy, Sitepoint etc. They should readily provide features needed to run this feature. But beware: You dont want a managed WordPress, cloud or other solution. They may not be configured for this feature to work.
A cheap shared linux hosting account like $3-5/month will allow you to test this feature and see if your setup and the demands of your site will be able to function in a shared hosting environment.
Only if you have a lot of images or a lot of traffic, large images etc, you may need something stronger. Like a dedicated, or a cloud hosting account which will allow you to access error logs and other important stuff.
Alternatively you can go with WPEngine, but they are pretty expensive for starters.
Amazon can definitely handle it; it’s far superior to any of the hosting platforms you’ve mentioned. It’s why I use them, because the site is 8 years old and has a lot of images and a lot of traffic. (So certainly not something that can be solved by migrating to a $5 tier environment.
But, it’s expensive too. I already pay £300 a month to host it there, so its a question of how much space does the plugin require and how much extra that will cost me.
Well, yeah, these details could have helped if shared earlier.
Image locking feature uses noticeably more resources when enabled. There isnt a way to remedy that with the current server/os infrastructure. What we are doing is redirecting requests to webserver, which would cause the webserver to just serve the image, to PHP, which will decide if it should be served, and if not generate an obscured image if necessary and cache it and serve it, or serve it if it is already cached before.
Its not a matter of space, it will only generate as much cached locked images as the images as you have.
Your problem will be the PHP process limits like time, memory etc, and the increased Amazon bill you will have. Also that you are not able to access error logs or see errors is a major problem.
…
If you are able to manage your own server, you could try a provider like Hetzner and get a high tier dedicated for that budget. Even better if you get the server from their ‘Server Bidding’ service. Mid to high tier dedicateds there are able to sustain ~1000 unique visitors / sec sustained even when WP is not using caching and the visits are hammering PHP directly. They also have cloud offerings, but with the dedicated option you can cut your existing and potential bill to a great extent. If you need it, you can set up small clusters with that budget if you would need it (i doubt you would need it).
Other than that, there is nothing we can do on our side to help you at Amazon in the current state of affairs.
Routing all requests for images through wordpress and dynamically generating the response will not scale well regardless of the amount of resources available to the site, it makes the cost of every single request very expensive. Although you could technically keep throwing more and more resources at the problem, it would become very expensive very fast and require constant monitoring to ensure there are enough resources available. I would highly recommend against it.
The goal – users should not be able to see images if they do not have permissions – can be solved in a couple of different ways that don’t require routing every request through wordpress – which is not viable for any website that has a high volume of requests regardless of the budget for compute resources.
There are many different traffic profiles for website, it’s important to remember that for well established websites that are authoritative in their niche there could be tens of thousands of other pages on the internet linking to their pages and images and there could be a significant request footprint coming from crawlers. Additionally, you can expect a single blog page to generate dozens of requests for images, which would mean enabling this feature would cause an exponential increase in the number of requests – and the average cost of each request would greatly increase too.
As an immediate hotfix that may reduce resource usage enough to allow your site to function with the protected image functionality enabled you could remove line 271 and line 278 from classes/patreon_protect.php which will bypass he dynamic image generation which is consuming a lot of resources on every image request – although the image displayed instead will contain the default $5 unlock prompt.
A scalable long term solution would be to offload responsibility for managing images to a CDN that supports authorization natively, for example AWS CloudFront supports Private Content with a couple of different authorization approaches (including signed URLs and cookies) and then on the clientside use the error event emitted by an img on authorization failure to populate with a contextually aware prompt to join the campaign at the required pledge level.
The dynamic locked images are cached. Therefore they shouldnt incur any load for their generation the next time they are loaded. Unless the image changes.
The only added ongoing load for such locked images is the load which is proportional to the difference in between the efficiency of Apache or Nginx reading an image file and serving it, and PHP reading a file and serving it. It shouldnt be a back breaking difference except in certain cases. Surely cant be as efficient as webserver directly serving the image…
One option to handle that would be to force generation of all locked images in a batch move by crawling entire site via a bot, or using code to force their generation. This would take generation of locked images out of the picture.
Other solutions like outsourcing the generation of these images to a dedicated server somewhere and then using the generated images etc are possible. But they are more complicated.
Also removing the code that generates locked image placeholders and showing a standard locked image whenever a locked image is requested without having access is possible. However this may not be so attractive and incentivizing to visitors and may not be as good as having originally generated images for conversion.
So I’ve had a technician working on the plugin, to reduce the database requests, and hopefully circumnavigate the issue of the site going down.
Although, the plugin itself doesn’t seem to be in effect. For example; I’ve attempted to lock this post with a $1 tier, but it hasn’t done it:
Also the image-locking feature, which is enabled on the plug-in on a copy of the site, doesn’t save the Patreon values required to lock it either.
It seems pretty much locked to me.
You may have a caching plugin or a form of server side caching that makes the content appear as it was before you locked. Which may effect the below too.
Also the image-locking feature, which is enabled on the plug-in on a copy of the site, doesn’t save the Patreon values required to lock it either.
Especially if you have Redis or similar.
Turns out I was just logged in, and needed to view it from another browser.
But I’m attempting to download the Patreon Pro plugin too. I get as far as is shown in the screenshot, then the wizard stops. When I then go to plugins area, it tells me to go back to complete the set-up.
Can’t find any manual installation instructions in the dashboard, but have tried uploading the plugins via FTP and the same thing happens.
Patron Pro support is rendered at CodeBard com. You can put a ticket there to get support for Patron Pro.