Presenting A Lightning-Fast And Enduring Cs-Cart Demo With 200,000 Products

Hello everybody,

We made a little test ourselves and we would like to share it

Demo store :

Server specifications :

Intel Core i7-6700 Quad-Core
Skylake+ Hyper-Threading
64GB DDR4 RAM
MySQL 5.7 + MyISAM tables
PHP 7.0.3 + OpCache + APCu
Redis for sessions
APCu for CS-Cart cache
---------------------------------------------------------
I took a category 2 cateogory pages from both stores.
First category:
First load response: 529ms
347 KB transfered | Finished : 1.47 S | Load 1.25 s
On refresh - Cached:
First response : this varies 192ms - 281ms
346 KB transferred | Finish: 1.28 s | Load 1.17 s
http://imageshack.com/a/img923/9145/o5jybZ.jpg

Second category:
http://highload.demo.cs-cart.com/computers-and-electronics/cameras-and-camcorders/camcorders/
First load response: 922ms
1.5 MB transferred : Finish :2.98 s | Load 2.54 s
http://imageshack.com/a/img923/8383/9kmnLH.jpg

On refresh - Cached
First load 600 ms
1.5 MB transferred Finish 2.56 ms Load 2.13 s
http://imageshack.com/a/img921/4223/p10VW6.jpg
----------------------------- Compared with --------------------------------------------------------
Our server specs
8 processors: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz
16 GB ram | 160 GB SSD drive
MySQL 5.7.12
PHP 7.0.5
First category
First load response: 1.33 s
382 KB transferred : Finish 2.45 s load 2.34 s
Refresh - Cached
First response 89 ms
50 KB trasnsferred | Finish 1.40s Load 1.29 s
Second category tested
First load 886 ms
251 KB transferred | Finish 1.83s | Load 1.72s
Cached
First response 85ms
39 KB transferred | Finish 1.22s | Load 1.03 s

http://imageshack.com/a/img921/271/ygUIMQ.jpg

The test is NOT quite relevant for many reasons

Servers are really different
  • Demo store 64gb ram with -- (this is just an assuption but i believe under 10 simultaneous visitors )
  • Our server 16gb ram , There were between 180 - 220 active visitors on the site
But there are 11 Stores on this server, yes, our nginx caching works with both multivendor and multistores, and I have no idea how many visitors were active on all websites. maybe around 2k ? so the sites are LIVE. Be careful if you want to order
  • Page size was different
  • Queries and number of request was different
However, I just wanted to point out, there are other options for caching, such as Nginx !
We used/use DO servers https://goo.gl/xZMRxb

Hello guys.

I've investigated the complexity of the LiteSpeed+LSCache full-page caching integration.

The basic caching functionality can be easily implemented, I mean the caching itself and ESI block loading.

However, the implementation of these features require a lot of job to be done:

* Targeted cache invalidation (i.e. all pages containing information about product with ID=1 will automatically be removed from cache after you've updated this product at the administration area).

* Multiple storefront support. Only one storefront will be supported.

Currently we don't have enough resources for developing the complex features listed above.

The targeted cache invalidation would be simpler to implement if LSCache support purging cache by tags, but it only supports purging cache for a specific URL (please, prove me if I am wrong).

Without targeted cache invalidation you'll have to purge ALL cache when you change the title of any product.

Other way is to set a tiny cache TTL which means you don't have to invalidate cache at all, but the changes you've made will be shown on site with a latency.

Please share your thoughts.

Invalidating the whole cache when product data is updated pretty much defeats the value of a cache if it is an active site.

Injecting a latency is okay as long as there is a URL parameter (or other simple means) that will defeat it.

This is mostly for us developers who go to work on a client's site without having complete details about a site (and most merchants won't know anyway). Right now, APC (or other external) caching can inject latency that drives one crazy when trying to insert logging or other diagnostics to help merchants. Same happens for cloud/cdn systems but not much can be done about that other than wait.

Or simpler yet, have it where if defined('DEVELOPMENT') && DEVELOPMENT then disable all external caching. Most sites I support have DEVELOPMENT defined if the user's IP matches a list in an array in local.conf.php. Right now I add an apc_clear_cache() when in DEVELOPMENT mode. Same should happen for other external caches.

Or simpler yet, have it where if defined('DEVELOPMENT') && DEVELOPMENT then disable all external caching. Most sites I support have DEVELOPMENT defined if the user's IP matches a list in an array in local.conf.php. Right now I add an apc_clear_cache() when in DEVELOPMENT mode. Same should happen for other external caches.

The fact is the next HTTP request after you've changed your 'local.conf.php' and defined 'DEVELOPMENT' constant may not trigger execution of the PHP at all because third-party HTTP-cacher like Varnish or LiteSpeed respond to the client with the page taken from its internal cache.

So your changes will not be taken into account :)

Making the site unsupportable....

Making the site unsupportable....

When we talk about our "Full-page cache" module you can just disable the add-on in the administration area and the caching will also be disabled.

Really like to see all these various options brought into one manageable area. You discuss moving to OO models. Here's an opportunity to start/demonstrate so that caching can be handled as an object and all properties manipulated within it. With the goal being that there is one simple switch to turn on/off and that can be done via an addon and/or the DEVELOPMENT definition. No need for any caching when in DEVELOPMENT mode. The addon could surely support the DEVELOPMENT constant.

Really like to see all these various options brought into one manageable area. You discuss moving to OO models. Here's an opportunity to start/demonstrate so that caching can be handled as an object and all properties manipulated within it. With the goal being that there is one simple switch to turn on/off and that can be done via an addon and/or the DEVELOPMENT definition. No need for any caching when in DEVELOPMENT mode. The addon could surely support the DEVELOPMENT constant.

Unfortunately, it's impossible to disable already enabled full-page caching after defining a constant for the reasons I've posted above

Hello Abolshakov, nice job

I want to aky you if is possibile to upgrade to addon for Varnish 4.1.x

I have just bought a vps and there is

varnishd (varnish-4.1.2 revision 0d7404e)
thanks!

Me install and enable addon - http://159.253.21.184/

But not see different in site response.

And site http://www.isvarnishworking.com/ says varnish not found.

Please explaine me, where my mistakes.

http://joxi.ru/MAjb0KefvBZqdA

Looks like you haven't installed or configured Varnish properly. I see that 80 port is being listened by the Apache HTTPD instead of Varnish on your server. Please take a detailed look to the configuration guide: https://github.com/cscart/full-page-cache-addon#configuring-environment

Hello Abolshakov, nice job

I want to aky you if is possibile to upgrade to addon for Varnish 4.1.x

I have just bought a vps and there is

varnishd (varnish-4.1.2 revision 0d7404e)
thanks!

Hi there, thanks. Unfortunately there is no quick fix for module to work with Varnish 4.1, if you want to try it out - you have to downgrade to 4.0. What is your operating system?

Looks like you haven't installed or configured Varnish properly. I see that 80 port is being listened by the Apache HTTPD instead of Varnish on your server. Please take a detailed look to the configuration guide: https://github.com/cscart/full-page-cache-addon#configuring-environment

Hi there, thanks. Unfortunately there is no quick fix for module to work with Varnish 4.1, if you want to try it out - you have to downgrade to 4.0. What is your operating system?

Hi abolshakov, i am on Debian 8

I'm not a linux expert, but if i can do it easily from ssh with a command i can try

Looks like you haven't installed or configured Varnish properly. I see that 80 port is being listened by the Apache HTTPD instead of Varnish on your server. Please take a detailed look to the configuration guide: https://github.com/cscart/full-page-cache-addon#configuring-environment

Hi there, thanks. Unfortunately there is no quick fix for module to work with Varnish 4.1, if you want to try it out - you have to downgrade to 4.0. What is your operating system?

is the highload demo terminated... 502 error

is the highload demo terminated... 502 error

I apologise for the silence, and would like to update the thread.

From time to time there were problems with MySQL on the server. It's should be fixed.

Also we updated the demo to 4.3.8

I apologise for the silence, and would like to update the thread.

From time to time there were problems with MySQL on the server. It's should be fixed.

Also we updated the demo to 4.3.8

Thanks for the update imac. I was actually wondering if this addon is compatible with 4.3.8. Did you make any changes to the addon to make it work with 4.3.8?

Btw, this message from first post is confusing. Github says 4.3.6 or higher, this should be reflected on the forum as well.

For now, the beta version of the full-page cache add-on is available on GitHub for free. The add-on only works with CS-Cart 4.3.6.

I can't remember where you mentioned but there was a topic where you mentioned removing ?t= from static assets (png, js, css). I still see this one being used as of 4.3.7. Everytime I do a webspeed analysis, I get "Remove query strings from static resources" that leads to this short explanation: https://gtmetrix.com/remove-query-strings-from-static-resources.html

Is there a workaround to remove timestamp from CS-Cart completely?

Hi abolshakov,

I checked with LiteSpeed Team and they told me that LSCache does support tag.
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:cache:lscwp:api?s[]=tag

I hope you can re-consider to support Litespeed.

Hello guys.

I've investigated the complexity of the LiteSpeed+LSCache full-page caching integration.

The basic caching functionality can be easily implemented, I mean the caching itself and ESI block loading.

However, the implementation of these features require a lot of job to be done:

* Targeted cache invalidation (i.e. all pages containing information about product with ID=1 will automatically be removed from cache after you've updated this product at the administration area).

* Multiple storefront support. Only one storefront will be supported.

Currently we don't have enough resources for developing the complex features listed above.

The targeted cache invalidation would be simpler to implement if LSCache support purging cache by tags, but it only supports purging cache for a specific URL (please, prove me if I am wrong).

Without targeted cache invalidation you'll have to purge ALL cache when you change the title of any product.

Other way is to set a tiny cache TTL which means you don't have to invalidate cache at all, but the changes you've made will be shown on site with a latency.

Please share your thoughts.

^Again I second this! Support for Litespeed and LS caching please. :-)

Today I tried to install Full_page cache addon on cscart 4.3.8 with varnish but it gave me this error: Version of your cart (4.3.8 ) is not supported. Minimal: 4.3.6. Maximal: 4.3.7. The addon version is 0.0.8. When we can expect addon version for latest cscart?

Hi everyone, this is George from LiteSpeed Technologies.

Good news.

We have added preliminary LiteSpeed support to the Full Page cache add-on, the forked project is at

https://github.com/litespeedtech/full-page-cache-addon

The port is pretty simple, by adding rewrite rules, changing to litespeed response headers, turning off varnish related checking.

Once we got some confirmations that it works as expected, we will submit a pull request to the official project.

To try this add-on, you can follow simple steps below

* install the addon as usual.

*manually modify .htaccess by adding the content in "htaccess_lscache" file in the root directory of the project at the beginning of .htaccess under store document root directory.

to disable cache, just comment out the added configuration in .htaccess.

For server and vhost cache configuration, you only need to set the "Cache Root".

Right this version completely disabled varnish support, so no need to try it with varnish, varnish should be stopped if you have it. Varnish detection can be easily added later.

With litespeed, You should get better performance, along with build-in HTTPS HTTP/2 support.

Even better yet, you can easily deploy it in shared hosting environment managed with hosting control panels.

You can apply a free trial of LiteSpeed Enterprise if you have not been using litespeed yet.

Great news George! Thank you.

Cheers,

Scott.