No this would not work, this would only work with the 'selective cache' option. The entire point of full page cache is not to have unique blocks that need to be rendered as this slows down the initial load.
I use a system with PHP 7.0, NGINX, Ubuntu 16.04 LTS together with 2 cores and 4 gb of RAM. I use this as this is as it is a fair baseline for common webservers.
Why Ubuntu if I may ask ? I see it very often CS Cart in combo with Ubuntu not so much on CentOS for instance ? Is configuring Ubuntu so much easier and or flexible or just an acquired taste ?
PS as a noob playing now with a setup of PHP 7.1, Apache, CentOS 7, MariaDB, 6 cores 10 GB of RAM.
Webmin yes not WHM Cpanel. Not yet able to figure out how to setup a hosting account on it and create an CSR for later SSL installation.
Ubuntu has CLAs, Debian has DFSG. Ubuntu releases a stable more often, but Debian has sid. Ubuntu has corporate backing directly, Debian does not. Those are the main differences. Also, Ubuntu is Debian based.
Okay, so I have some exciting news. I have finally done some more optimisation and perfected the addon a bit more. I decided that I will release 2 seperate add-ons.
1. Selective Cache which will allow you to select what blocks you would like to cache.
2. Full Page Cache which speaks for itself.
This is because of the fact that Selective Cache is still not optimised. E.g. it uses a central database to keep track of the cache statuses instead of my custom cache system that I built for the Full Page Cache add-on.
Nonetheless, I have installed my add-on on a demo store and benchmarked it.
I used a server with just 2 cores (with hyperthreading) and only 4 GB of ecc ram. CS-Cart settings were basically the same, however, I did enable redis caching for the sessions.
Next I set up a load program on my own desktop and created a load of 200 unique users. This resulted in the graph that is attached. Pretty impressive, right? Soon I will also open a public demo, though I simply haven't had the time for that in the past few days.
Expect only the full page caching add-on to be released in the next few days (with a price of €100)!
Okay, so I have some exciting news. I have finally done some more optimisation and perfected the addon a bit more. I decided that I will release 2 seperate add-ons.
1. Selective Cache which will allow you to select what blocks you would like to cache.
2. Full Page Cache which speaks for itself.
This is because of the fact that Selective Cache is still not optimised. E.g. it uses a central database to keep track of the cache statuses instead of my custom cache system that I built for the Full Page Cache add-on.
Nonetheless, I have installed my add-on on a demo store and benchmarked it.
I used a server with just 2 cores (with hyperthreading) and only 4 GB of ecc ram. CS-Cart settings were basically the same, however, I did enable redis caching for the sessions.
Next I set up a load program on my own desktop and created a load of 200 unique users. This resulted in the graph that is attached. Pretty impressive, right? Soon I will also open a public demo, though I simply haven't had the time for that in the past few days.
Expect only the full page caching add-on to be released in the next few days (with a price of €100)!
The add-on will be released on friday evening, right now a few clients from me are testing the add-on. (Clients that have a managed hosting subscription have the ability to preview / get any add-on from my store that they want).
No this would not work, this would only work with the 'selective cache' option. The entire point of full page cache is not to have unique blocks that need to be rendered as this slows down the initial load.
Thanks, so just making sure I understand, I can select this block so it won't be cached and does update?
Thanks, so just making sure I understand, I can select this block so it won't be cached and does update?
Not as of right now, but I am trying to create some sort of render function that will allow me to replace certain parts of the code, hence the Full Page Caching add-on hasn't been released yet.
So how I want this to work is:
1. You select a block in the backend (which has to be excluded).
2. The full page caching add-on removes the piece of code required.
3. On load it will check the array scheme that will be saved along with the page (so block ID and such will be included).
4. It will str_replace (or something else) the necessary parts.
Does anyone use this plugin or have a version of it working with Nginx? I've been trying to get something like this to work, but seem to get most of my cache hits to BYPASS. Not sure if the plugin version I was able to download in a previous message on this thread was incomplete? But I can't get to the poppedweb.com site - seems to be down. Just looking for a little guidance on getting Nginx cache working reliably with CS Cart. Many thanks!
So are you saying the ONLY way to get caching to work with CS Cart is Varnish?
You could get it to work, if you can make it so that whenever you submit a unique request, a cookie gets automatically set that will force you to only see new and fresh content. You will also need to make sure that your app server checks if any user data is present on the page before saving the cache (so that you don't leak user data after invalidating a cache).
Besides, this type of caching is very, very, very use case specific. This only works with e.g. flash sales where a bunch of users instantly view a product and then leave again. For every other use-case autoscaling is probably the way to go.
However, you could also just use ESI with NGINX, which is basically how varnish works.