RM365 Performance Audit

Store Profiling
RM365.FR
Jul-22
Introduction
Sonassi has analysed the RM365.FR store to discover potential performance issues.
This profile should not be considered a definitive list of all issues but more of a summary of
problem areas that could cause reduction in capacity or speed for the store.
Throughout the document scores are used to indicate the significance of issues found:
Serious issues that need to be fixed or investigated urgently.
Issues that need fixing but are not considered serious.

These could impact performances, site speed and stability.
Possible future improvement
No issues found
Your audit is split into four parts:
1. Stack: We review your store setup on your stack to make sure you are making use of
Sonassi’s inbuilt performance enhancements
2. Frontend: We take timings from key pages, and review issues which might block
loading of key areas of your store
3. Backend: We review modules to ascertain what affects your overall load speed
4. Logs: We review your logs to understand recent activity on your store
2
Executive Summary
The RM365.FR store performs below average across all areas. The store is setup to use all
of Sonassi’s enhancements correctly (see Stack).
As a first point of call, RM365.FR need to investigate their low cache hit rate. This is causing
extra load to the stack, as well as slowing down the store for customers.
Redis is correctly setup on the stack.
Cron has not been setup correctly as per Sonassi’s recommendations. This could introduce
security and stability issues if not addressed.
Grouping collections of scripts and stylesheets together into one file will drastically improve
page speed, often as much as halving them. Implementation time varies depending on
modules (see Reduce Requests).
Several modules cause a big amount of extra load time on the store. Where possible these
should be optimised or removed.
3
Key Details
Date of test 2022-07-06
Store URL https://www.rm365.fr
Magento version 2.4.3-p2 (PHP 7.4)
Cache enabled Magento Caches, Redis, Varnish
Search Engine Elasticsearch 7
Stack stack1.c867
CPU 8 Core 3.5GHz
Memory 32GB
Magento Version
Magento bring out a new release every quarter. New releases include critical security
patches, bugfixes and improvements.
We suggest that all store owners endeavour to keep up to date with the latest version
available.
The current version of the site is 2.4.3-p2 which is 1 release behind the current 2.4.4 release.
We recommend you update to the latest version.
4
Stack
Sonassi have checked the configuration of your stack to verify your resources are sufficient
for your store, and you are using all available Sonassi enhancements.
What we check Why we check it
Resource Usage We check that your stack has the right resources for your store
Caching is a crucial part of Magento which reduces load and
Cache usage increases capacity. We check that all caches are setup and
working as expected.
Magento relies on scheduled tasks to make changes after an
event, rather than in real time.

Scheduled Tasks
We check your scheduled tasks are setup in a secure and stable
way.
5
Cache Storage (Redis)
By default, Magento stores cache entries within file-based storage in individual files.
Reading files adds a large overhead to accessing cache entries slowing down stores and
reducing capacity.
Redis is a database facility used to store cache entries. Sonassi have inbuilt Redis cache
storage which we recommend all customers use for best performance.
The RM365.FR store was setup to use Redis. We could see that data was correctly being
stored Redis.
Figure 1: The main domain is setup to use Redis for all cache storage
6
Cache Storage (Varnish)
When a customer goes to a page on your store the request goes to your stack and is handed
onto Magento to process it.
Magento looks for a matching entry within its cache, and where available this is returned. In
some cases, pages cannot be cached and must be generated on-the-fly for customers. This
is a resource-intensive action, so we look for a high cache hit-rate to increase speed and
capacity.
Requesting any page from Magento is an intensive action, even when cached. Magento is a
heavy application which requires a large amount of resource just to check for a matching
cache entry.
Sonassi have an additional caching layer available – Varnish. Varnish holds the cache on the
server-side.
Magento suggest all merchants use Varnish:
‘We strongly recommend you use Varnish in production. The built-in full-page
caching (to either the file system or database) is much slower than Varnish, and
Varnish is designed to accelerate HTTP traffic.’ Extract from Magento Devdocs
RM365.FR have activated Varnish on the store correctly.
[___general]$ cat rm365.fr.conf | grep magestack_cacheable

set $magestack_cacheable true;
Figure 2: Caching is enabled correctly on the server-side
[http]$ cat app/etc/env.php | grep -A5 http_cache_hosts
'http_cache_hosts' => [
'host' => 'lb1.i',
'port' => '80'
],
Figure 3: Magento is set to use Varnish and it points to the stack correctly.
7
Cache Hit Rate
Dynamic pages such as the checkout are marked as uncacheable by default so that each
user gets an individual result.
These pages must always be processed by Magento. As pages returned from Magento are
more resource intensive all merchants should strive to have as much content stored in
Varnish as possible.
The graph below shows the RM365.FR hit rate, currently averaging 56.07%.
This hit rate is low, an average above 70% should be expected.
This suggests that cache is flushed too often, or pages contain elements that set the
cacheable Magento attribute to false.
Figure 4: Cache hit rates. Currently averaging 56.07%
8
Cache Lifetime
Content will stay in Varnish until its expiration date. This is controlled by the lifetime set by
Magento (TTL).
On RM365.FR the lifetime is set to 24 hours, meaning the content will be cached for longer,
resulting in better performances and less resource usage.
Figure 5: Varnish in use, but lifetime set to just 24 hours
9
Elasticsearch
Elasticsearch is a database used to store data for use in searching. Elasticsearch is used for
all product lister pages on the store, as well as for general searches.
Elasticsearch has a memory limit of 1000MB. RM365.FR is using too much memory, causing
performance degregation to the store.
Figure 6: Elasticsearch memory usage
10
Scheduled Tasks (Cron)
Magento performs numerous tasks on a scheduled basis. As an example, Magento caches
pages that customers see for best performance. When a product is changed in the admin
the cache then needs to be cleared for this product. This happens on a scheduled task.
Magento’s default scheduled task configuration has security issues as it is allowed full
access across the stack. This means that it can access files which is should not be allowed
access to.
At times scheduled tasks can take longer to complete than expected. When this happens
tasks can become backed up causing huge store issues.
Sonassi have defined a secure way to run Magento’s scheduled tasks without the risk of
long running tasks causing backlogs. RM365.FR is not using Sonassi’s method for
scheduled tasks, which can leave the site exposed to security and stability issues.
Figure 7: Scheduled tasks running on the stack
11
Resource Usage
Sonassi have analysed usage of key resources on your stack to check that your usage is
safely inside limits.
CPU Load
We look to see usage at around 25% of the available CPU capacity. This allows for the
occasional large spike without causing the store to go offline.
The current load is around 5% which is a well within the limits. However, there are also a
number of noticeable spikes which should be investigated to reduce unnecessary resource
usage and stress on the stack.
Figure 8: CPU load average
12
Memory Load
Sonassi stacks use memory as much as possible for peak performance. We split memory
usage into memory which is required for the store to function (here in dark green), memory
used by the operating system for caching (from the darker green section up to the purple
section), and memory available for use (here in a light green).
Stacks will keep using memory until it is all in use, at which point they will use a small
portion of their storage as emergency memory (also known as swap). As such we expect a
high utilisation rate.
On this stack we can see memory usage is well within expected thresholds.
Figure 9: Memory utilisation
13
Frontend Profiling
When a customer visits your store the first part of the wait is for your store to return the
instructions for the browser to build the page, these instructions are in HTML, and the time a
customer waits here is the time to first byte (TTFB).
Once the HTML is returned the browser works through the instructions one line at a time.
Lines can be simple instructions (e.g., show X some text) or more complex instructions,
such as telling the browser to download images or scripts.
For each additional file the browser has to download each line of this must be read and
interpreted.
Scripts can add functionality to a page, like tracking the users details to third parties like
Google Tag Manager or showing the customer the items in their basket.
In the majority of cases well cached page will have a very low TTFB, and the loading time will
be made up of downloading content and processing it.
Our frontend profile analyses each page to gather details of the TTFB, browser load time and
the size of the page. Using these we can determine where the biggest performance cost
occurs to help you understand how to optimise your store.
14
Pages Analysed
Several pages that make up key part of the user journey are picked for deeper review:
Page URL
Homepage https://www.rm365.fr/
Product listing page https://www.rm365.fr/combleurs-dermiques.html
Product details page https://www.rm365.fr/aliaxin-gp-2-x-1ml-d-n-003.html
Search page https://www.rm365.fr/catalogsearch/result/?q=bcn
Cart page https://www.rm365.fr/checkout/cart/
Checkout page https://www.rm365.fr/onestepcheckout/
Success page https://www.rm365.fr/checkout/onepage/success
15
1. Homepage
Figure 10: Screenshot of the homepage
Analysis
The homepage is a key landing page for customers. We look for a quick page, which always
gets cached to limit load on the stack (see Stack section for more details).
Lazyloading is used on the page for images reducing the page size.
The page was cached correctly in Varnish resulting in a decent time to first byte (TTFB).
The overall page time was well within the expected thresholds.
The page size was larger than expected. This is caused by a large amount of images being
downloaded on the page.
16
Results
Test Expected Actual Difference
Time for results from

the application Less than 200ms 25ms -175ms
(TTFB)
Time for the browser

to load content (load Less than 2000ms 1250ms -750ms
time)
Page size Less than 2048KB 8200KB 6152KB
17
2. Product listing page
Figure 11: Screenshot of the product listing page
Analysis
Product lister pages typically suffer from a slow speed when the number of products loaded
is high, or when the images are loaded on page load. Pagination is set to 24 which is higher
than our recommended value of 12.
The page size was larger than expected. This is caused by a large number of scripts being
18
Results

(TTFB)

time)
19
3. Product details page
Figure 12: Screenshot of the product details page
Analysis
Product detail pages typically load a large product image as well as thumbnails on page
load. A larger page size is expected here.
20
Results

(TTFB)

time)
21
4. Search page
Figure 13: Screenshot of the search page
Analysis
Site search is the functionality that enables users to search a given website’s content or
product catalog with speed and relevance. A great site search function is tailored to the
specific website. Site search constantly index the site to ensure the latest content is easily
accessible, it also guides users as they explore a website’s content, helping them discover
content they might not have even known they were interested in.
22
Results

(TTFB)

time)
23
5. Cart page
Figure 14: Screenshot of the cart page
Analysis
The cart page is typically slow from an application level. The page cannot be cached and on
page load some data processing has to be completed to generate the quote for the
customer.
As expected, the page was not cached in Varnish resulting in an increased time to first byte
(TTFB).
loaded on the page.
24
Results

(TTFB)

time)
25
6. Checkout page
Figure 15: Screenshot of the checkout page
Analysis
The checkout page is typically slow from an application level. The page cannot be cached
and on page load some data processing has to be completed to generate the quote for the
customer.
(TTFB).
loaded on the page.
26
Results

the application Less than 200ms 1090ms 890ms
(TTFB)

to load content (load Less than 2000ms 1810ms 190ms
time)
27
7. Success page
Figure 16: Screenshot of the success page
Analysis
The cart page is typically slow from an application level. The page cannot be cached and on
page load some data processing has to be completed to generate the quote for the
customer.
(TTFB).
loaded on the page.
28
Results

the application Less than 200ms 700.25ms 500.25ms
(TTFB)

to load content (load Less than 2000ms 1650ms 350ms
time)
29
Frontend Recommendations
Following our review of your frontend, we recommend you make several changes to improve
load time.
Sonassi can assist with any recommendations as part of a store support arrangement if
required.
30
Reduce Requests
As explained in Frontend Profiling, a single page load results in numerous other pages being
requested, such as images and scripts.
Each request takes time for the users’ browser to make the request and time to return it.
Multiple files can be combined into one, a process known as bundling.
File size can be reduced by removing none-essential parts, this is called minification.
Minification was correctly setup, reducing file size for JavaScript and CSS files.
Bundling is not in use. Setting this up would drastically improve page load time and improve
Google Pagespeed scores. Sonassi can assist further with this if required.
Page Requests
Homepage 276 requests
Product Listing Page 369 requests
Product Details Page 420 requests
Cart Page 495 requests
Checkout 680 requests
Success Page 325 requests
31
Backend Profiling
Backend profiling involves a review of the modules that make up your store. We find
modules that either reduce capacity by using large amounts of resource or reduce
performance by slowing down the page load time.
We clone your production site to our own stack so that we can safely make changes without
affecting your store.
We review:
1. CPU usage
2. Memory usage
3. Network input/output
4. Database requests
5. HTTP requests
From each of these matrixes we determine exactly which modules take the largest
percentage of the resource.
We then disable modules which have the biggest effect on the store and run the profile
again.
We compare the two profiles and give you these results along with our insight of which part
of the module causes the usage.
32
Mageplaza_Osc
What is it?: One step checkout for Magento 2, replaces the default Magento checkout
showing all information in one page.
What effect does it have on the store? It considerably increases page load time on
checkout.
Page Increase in page load time
Checkout page 18%
Suggestions: If possible Magento default checkout should be used instead, making
checkout quicker, increasing usability for a better user experience and making maintenance
easier by using default functionalities instead of custom ones.
33
Smartwave_Megamenu
What is it?: The Smartwave Megamenu module, allows for additional customisation of the
default Magento 2 megamenu.
What effect does it have on the store? It increases the page load time on the following
pages.
Homepage 9.06%
Product Listing page 18%
Product Details page 17%
Cart page 29%
Checkout 12%
Success page 36%
Suggestions: Module to be reviewed for problematic bottlenecks. Also recommended to
cache elements where possible, in order to reduce impact on page performance.
34
Dotdigitalgroup_Email
What is it?: Together with Dotdigitalgroup_Chat implements the integration to dotdigital.com
services.
What effect does it have on the store? It adds extra operations during the order creation,
payment processing and on the success page
Suggestions: the module is not being used on the live site it can be disabled to exclude the
extra operations.
35
Smartwave_Filterproducts
What is it?: The Smartwave Filterproducts module, allows setting options for filtering
products, such as featured products, best selling products etc.
What effect does it have on the store? This module can cause negative impacts on pages
where it’s implemented, leading to increased page load times.
Homepage 5.89%
Suggestions: Optimise code and enable caching on elements where possible. If the module
is not relevant to the page or is not adding any potential benefits, then it should be removed
to decrease page load time.
36
Store Activity Review
Sonassi has analysed the activity of the users on the website in the last 48 hours to discover
potential content or security issues.
404 Content
Figure 17: 404 content within the last 48 hours
When a browser makes a request, if the content is not cached Magento must be called to
provide the result. Magento has to check all possible rewrite rules to determine what to
return. This whole process is incredibly costly to server resources.
RM365.FR have 4342 404 (page not found) results logged. This means that Magento is
being called regularly without being able to find anything.
37
Suggestions: Most of the 404 activity seems to be caused by Bots hitting the website, this
can be reduced by controlling what Bots are meant to index via robots.txt, sitemap
configuration and blocking unwanted Bots from visiting the site. Reviewing SEO on the site
is also be recommended.
Figure 18: 404 content within the last 48 hours
38
Error Responses
On each request a store can return many different response codes to the customer to
indicate the response. We hope not to see any 50x errors, which indicate that the request
returned an error.
Here we can see in the last 48 hours the store averages around 186.
Figure 19: Status codes - shows occurrence of 50xs
39
Visitor Analysis
The top countries were found to be France, UK, Germany, United States, China .
If any of these countries are not countries RM365.FR ship to, they should be blocked.
Figure 20: Visits by Country
40

RM365 Performance Audit

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RM365 Performance Audit

Uploaded by

Copyright:

Available Formats

Store Profiling

Serious issues that need to be fixed or investigated urgently.

Issues that need fixing but are not considered serious.

Possible future improvement

Your audit is split into four parts:

Sonassi’s inbuilt performance enhancements

loading of key areas of your store

4. Logs: We review your logs to understand recent activity on your store

of Sonassi’s enhancements correctly (see Stack).

Redis is correctly setup on the stack.

security and stability issues if not addressed.

modules (see Reduce Requests).

should be optimised or removed.

Date of test 2022-07-06

Store URL https://www.rm365.fr

Magento version 2.4.3-p2 (PHP 7.4)

Cache enabled Magento Caches, Redis, Varnish

Search Engine Elasticsearch 7

CPU 8 Core 3.5GHz

patches, bugfixes and improvements.

We recommend you update to the latest version.

What we check Why we check it

Caching is a crucial part of Magento which reduces load and

Magento relies on scheduled tasks to make changes after an

event, rather than in real time.

storage which we recommend all customers use for best performance.

onto Magento to process it.

Magento suggest all merchants use Varnish:

Varnish is designed to accelerate HTTP traffic.’ Extract from Magento Devdocs

RM365.FR have activated Varnish on the store correctly.

[___general]$ cat rm365.fr.conf | grep magestack_cacheable

Figure 2: Caching is enabled correctly on the server-side

[http]$ cat app/etc/env.php | grep -A5 http_cache_hosts

'host' => 'lb1.i',

'port' => '80'

user gets an individual result.

This hit rate is low, an average above 70% should be expected.

cacheable Magento attribute to false.

Figure 4: Cache hit rates. Currently averaging 56.07%

resulting in better performances and less resource usage.

Figure 5: Varnish in use, but lifetime set to just 24 hours

performance degregation to the store.

Figure 6: Elasticsearch memory usage

Magento performs numerous tasks on a scheduled basis. As an example, Magento caches

tasks can become backed up causing huge store issues.

Figure 7: Scheduled tasks running on the stack

safely inside limits.

occasional large spike without causing the store to go offline.

number of noticeable spikes which should be investigated to reduce unnecessary resource

usage and stress on the stack.

Figure 8: CPU load average

section), and memory available for use (here in a light green).

high utilisation rate.

Figure 9: Memory utilisation

customer waits here is the time to first byte (TTFB).

such as telling the browser to download images or scripts.

be made up of downloading content and processing it.

occurs to help you understand how to optimise your store.

Product listing page https://www.rm365.fr/combleurs-dermiques.html

Product details page https://www.rm365.fr/aliaxin-gp-2-x-1ml-d-n-003.html

Search page https://www.rm365.fr/catalogsearch/result/?q=bcn

Cart page https://www.rm365.fr/checkout/cart/

Checkout page https://www.rm365.fr/onestepcheckout/