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

Hi!

The more products and visitors your store has, the higher load it has to withstand. If the number of products and simultaneous visitors exceeds the number a store and its server can handle, the store dramatically slows down and can crash.

Thanks to the latest improvements, such as full-page caching and PHP 7 support, CS-Cart now works as fast as usual and handles a high load even with 200,000 products on board.

To demonstrate the stamina of a properly configured CS-Cart store with full-page caching, we’re presenting a special highload demo and its test results.

Full-Page Caching

CS-Cart 4.3.6 now supports a new Full-page cache add-on which allows your store to handle more visitors.

The full-page caching works via Varnish, allowing your store to withstand a higher load and speed up page loading on the first and repeated visits up to 25 times.

This is how it works: when a customer opens a page, CS-Cart stores (i.e. caches) that page into memory. When another customer opens the same page, CS-Cart quickly retrieves it from memory. As a result, the second customer gets that page quickly—even on the first visit.

How to Get the Full-Page Cache Add-On

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.

The add-on requires proper configuration of the server environment. Check out the instructions in the repository and make sure you are skilled enough to configure. If you think the configuration is too complicated, hire a high-level tech specialist for this job. You can also contact us via our Help Desk to get a consultation and advice, of course.

Since this is a beta version, the add-on has 2 restrictions for now:

  • it doesn’t work for Multi-Vendor
  • it only works with one storefront

We plan to enhance the Full-page cache add-on as soon we collect feedback. If you think your store is under a high load and badly needs a performance boost, try the Full-page cache add-on and please share your opinion.

Performance Testing

To show the performance of a properly configured CS-Cart store with full-page caching, we created a highload demo store and tested its stamina.

We took a dedicated server with a quad-core Intel Core i7 processor and 64GB DDR4 RAM for €39/month, installed CS-Cart, and configured it for full-page caching.

Then we imported 200,000 products with 11,000 features, arranged those products into 1,000 categories, and added product filters:

For the testing, we used Yandex.Tank, which checks how many transactions per second a store can handle.


A transaction includes a request to the server that a customer makes when clicking a link or searching for products, and a response from the server which results in an opened page or search results. The more transactions per second a store handles, the better.

In the testing, we made requests to 2,000 products and 100 categories: 5% of requests by authenticated virtual customers, another 5% by virtual customers with products in their carts, and 90% by virtual guests:

Testing Summary

Conclusion: a properly configured CS-Cart with full-page caching on the above server configuration handles 980 transactions per second, which means:

We’ve also tested the highload demo without full-page caching and dividing virtual customers into groups, and we got 160 transactions per second.

Keep in mind that on more powerful servers with Intel Xeon processors, the number of transactions per second dramatically increases. To achieve even better results, you can share the load between several servers.

----

You are welcome to check the highload demo yourself. Please tell us your thoughts about full-page caching here in this topic and please report any issues of the demo to our bug tracker.

If you follow us on Facebook and Twitter, you won’t miss any of our latest news and announcements.

When FPC avalible for Multiveindor ver?

This is cool and very promising. Look forward to the MV compatible addon.

Are you going to push it further and implement ESI?

How about LiteSpeed?

Wow! I'm impressed. I'm using cs-cart for more than 7 years now, and never seen it fast as this before. I did have a good run with v1.35, but it is way outdated, and was forced to switch to v4. Will you include the add-on in next cs-cart release?

Really looking forward, we all need this.

When FPC avalible for Multiveindor ver?

Hi!

We plan to implement full-page caching for Multi-Vendor in the future, but first we need feedback to polish everything.

Will you include the add-on in next cs-cart release?

Hello!

We don't plan to include it into default release build, because using it requires advanced server configuration.

Are you going to push it further and implement ESI?

How about LiteSpeed?

Hello!

ESI is already supported. When the user is not logged in, but, for example, has a product in the cart, the content of "Cart content" block is being loaded via ESI, while the other content of the page is retrieved from the cache.

We will investigate the complexity of integration with LiteSpeed and make a decision whether to implement it in a near future.

Dear Team

Congratulations!! The demo is fantastic. Even a single character search (say "a") loads results in a few seconds (confirming around 2,00,000 products).

All operations, including Add to Cart are lightening fast! I am sure the cart will easily support 100s of concurrent users, even with moderate servers.

Just curious : does the full page caching support Hole Punch? The pages still seem fast after add to carts etc. Also is the cache warmed automatically, or based on user interactions?

Again, many congratulations - I think this demo is the fastest cart I have test driven, including the non static operations, customer areas etc.

Warm Regards

Hello ramesh,

does the full page caching support Hole Punch?

As I already explained:

When the user is not logged in, but, for example, has a product in the cart, the content of "Cart content" block is being loaded via ESI, while the other content of the page is retrieved from the cache.

Cache is not being warmed in automatic way.

We will investigate the complexity of integration with LiteSpeed and make a decision whether to implement it in a near future.

Thanks. That would be great. I'm sure that if you reach out to Michael @ litespeed that he will help you where he can.

server with a quad-core Intel Core i7 processor and 64GB DDR4 RAM for €39/month, installed CS-Cart, and configured it for full-page caching.


Where / which ISP did you host this server ?

server with a quad-core Intel Core i7 processor and 64GB DDR4 RAM for €39/month, installed CS-Cart, and configured it for full-page caching.

Where / which ISP did you host this server ?

Hello!

We hosted the demo at Hetzner (not an advertising), learn more about the used plan here: http://ru.hetzner.com/hosting/produkte_rootserver/ex41s

Hi,

I always (for years) curios about this: on the pagespeed there are recommendations on how to remove blocking scripts and some more things to do for speed improvement. Is it hard to obey right order or you frankly ignore them? Is there a reason why not to brush cs-cart code?

Hi,
I always (for years) curios about this: on the pagespeed there are recommendations on how to remove blocking scripts and some more things to do for speed improvement. Is it hard to obey right order or you frankly ignore them? Is there a reason why not to brush cs-cart code?


Hello!

Not an every recommendation of Google Pagespeed leads to improved user experience on a websites which look differs from a simple personal homepage.

The only blocking resource for now is the main CSS file, containing all stylesheets. If we move it to the bottom of the HTML, the Google's warning will disappear, but we don't do it consciously.

Moving CSS file to the bottom will lead to an effect of "jumping white page". Browser will render all HTML using its default stylesheets and show it to the user.

The page will look like this:



After that, when the CSS file will be loaded, it will repaint the entire page several times, which content will shrink and stretch each time randomly.

Obviously, that behavior leads to the negative user experience at all.

Other recommendations are only related to the server configuration and not to CS-Cart code.

Since you used a server with 64GB of memory, can you provide any test results (load test, speed test) with configurations that might more closely match a common VPS (or cloud) configuration? I.e. maybe 4GB of memory versus 64GB. And yes, please use your same product counts and other factors so we can get a relative sense of an impact for memory.

When you did your tar/zip performances, you used a very small (unrealistic) data set size that easily fit into memory. And now you're using an mostly unrealistic memory configuration when in other articles you (cs-cart team) recommend 2GB for the vast majority of merchants (which I believe to be too low).

Would really like to see a table of performance impacts for a variety of factors including:

+ physical memory (2G, 4GB, 8GB, 16GB, 32GB, 64GB)

+ physical cpu (2-core, 4, 8, 16)

+ number products (1K, 4K 16K, 64K, 128K, 256K)

+ concurrent users recalculating carts, searching for product features, doing product comparisons, some image resizes, etc. I.e. the things real users do or experience.

Like to see a table/graphs of the above configs/results so people can actually evaluate impacts of changes relative to their needs.

Just two-cents of input.

Would really like to see a table of performance impacts for a variety of factors including:

+ physical memory (2G, 4GB, 8GB, 16GB, 32GB, 64GB)

+ physical cpu (2-core, 4, 8, 16)

+ number products (1K, 4K 16K, 64K, 128K, 256K)

+ concurrent users recalculating carts, searching for product features, doing product comparisons, some image resizes, etc. I.e. the things real users do or experience.

Like to see a table/graphs of the above configs/results so people can actually evaluate impacts of changes relative to their needs.

Hello!

As I understood, you're talking about determining an extended list of server system requirements for a several scenarios.

I think that results will not be relevant for everyone, because there are too many factors that may influence the performance, which are specific for each merchant.

And now you're using an mostly unrealistic memory configuration when in other articles you (cs-cart team) recommend 2GB for the vast majority of merchants (which I believe to be too low).

I think there are no "realistic" memory configurations. Each configuration is individual: when we talk about a large amount of products (> 10000), categories and a high user traffic, your server should be chosen, configured and supported by a technical specialist that will investigate bottlenecks in your system with existing and potential loads - this is their job.

Talking about server specs, I have to note the following statements:

+ physical memory (2G, 4GB, 8GB, 16GB, 32GB, 64GB)

When it comes to choosing amount of server memory - the generic recommendations don't work, this is done individually after an analysis of existing environment and loads.

The simplified formula may look like: (size of the database * 2) + (average memory usage of php-fpm child * FPM max childs), but it also depends on what software is running on the same server - Redis, Varnish, DNS server or maybe postfix.

It also depends on PHP version being used, MySQL storage engine, MySQL cache settings and so on. You may face a lot of problems if your load scenarios even a bit differs from any benchmarks, for example when the product images are being updated often you'll face a high memory usage by the image manipulation libraries and binaries that create thumbnails.

+ physical cpu (2-core, 4, 8, 16)

The cores count is not an indicator of potential performance. The 2 physical cores of Xeon E3-1230 and 2 physical cores of any Atom processor provide dramatically different performance.

Providing results for cs-cart customers when using dedicated servers with 64GB memory configurations is in fact unrealistic. Pay $400 for software and spend $500+/month for a server to run it?

I have clients that run 225K products in V3.0.4 cs-cart with 12GB memory and a few cpu's. So 100K products isn't really a big deal

Anything will run fast if you cache it all in memory (like the old SHM caching method used in V3) and then have the DB cached in memory as well. That's not rocket science and says nothing about the software itself but rather what you can spend to host it.

Now you're getting silly in your response. Find me a host that runs atom processors on a server. We all know that different cpus have different core counts and different clock speeds and different internal caches (all of which make a huge difference). My point was to show performance across a scaling of HW configurations as well as product/site configs.

And don't forget the software variants that impact performance as well. Things like number of cart promotions, product features, product comparisons, etc.

My point is that your configuration and results is not relevant to 99.9% of your customers. Great news for you internally as it relates to Merchium but not relevant at all to your bread and butter customers. You know, they guys who pay your bills/salaries.

You've effectively shown one data point that is irrelevant to the vast majority of your customers. My request was simply to provide performance/configuration info that might help 99% of your customers versus 0.01%.

If as merchant and small hosting company I have for our own business one VPS with the following specs

8 GB memory

PHP 5.6

MySQL 5.6

CentOS 6.7 - 64 Bit

XCache

Redis

40 GB Solid State Drive Space

I run three CS Cart stores on it, three V4.3.x stores. Our main store with around 400 products and the others just 20 respectively 80.

Now I also host four other VPS for other clients of which 3 similar spec virtual machines are currently vacant.

If I had the option to have one store serviced with 64 GB I for sure might reach similar scores but as I agree with Tony I do not think that is very realistic.

Plus if I may remind you that you use the default responsive theme without many eye candy. If I were to throw our theme in the woods that might result in the same league eventually.

A question for Tony, should we increase it to 12 GB per VPS as well ?

My thoughts and question on this topic.