Magento hautement performant – comment gérer facilement 8000 commandes par jour dans Adobe Commerce

Ce que vous apprendrez après avoir lu cet article :  

• Quel travail est nécessaire du côté d'Adobe Commerce pour s'assurer qu'il peut supporter la charge ;  
• Quel travail est nécessaire du côté de l'hébergement/du cloud pour gérer autant de commandes ;  
• Les questions à poser à l'équipe de développement pour s'assurer qu'elle est prête ;  
• À quelles questions l'équipe métier doit-elle répondre pour s'assurer que votre entreprise est préparée ;  

Quelle est la différence entre Magento et Adobe Commerce (et Adobe Commerce on Cloud) ?

First, let us investigate some key differences between these – at first glance – identical platforms; Adobe Commerce is a licensed version of Magento 2 and has all the basic bells and whistles. Additionally, it sparks a few new features like full B2B support, a loyalty program, content scheduling, segmentation and so on – but those are only features. There are also a few more, not-so-obvious changes, if you look under the hood. 

The first one is the database change because of the scheduling system. As there can now be multiple instances of, for example, page or attribute, a simple entity ID row is not enough to be a primary key; in many places, row id is also added. This creates the need for new sequential tables that allow us to handle trigger fallbacks for all tables using new entity/row ids;  

The second one is the order archive – this allows us to tidy up the order table, so it is not only  easier to read and scan for the customer service team, but also each database query will be faster as there are fewer data entries to scan; This does not seem to be much at first glance – but considering the fact, that after just ten weeks we would have 15 thousand orders to scan, we could easily shave off few milliseconds of each page request;  

Pour couronner le tout, il y a aussi Adobe Commerce in the Cloud. Il s'agit essentiellement d'Adobe Commerce dans une solution cloud prédéfinie qu'Adobe propose en vente additionnelle à ses clients ; son efficacité en termes de coût et de performance est une toute autre histoire.   

Commençons par le début. 

Configuration

Toute la configuration de base qui pourrait être effectuée du côté de Magento n'affecte pas les performances. Cependant, si vous commencez à aller plus loin, quelques modifications mineures apportées à une ou deux options pourraient, en fait, rendre le site deux fois plus lent. 

The configuration to be most cautious about is Catalog Configuration. For example, how many products are shown on the product listing page (PLP for short)? In this case, “less is better” is a solid strategy. It is also important to make sure that clients do not have too many options to change the number of visible products (Is infinite scroll and ajax loading a good strategy? Well, to be discussed another time). An optimal number of products from a dev point of view would be 3 rows multiplied by how many products you want to see in a row on a desktop – usually it ends up being 6, 9 or 12.  

There are also a few configurations – like an already legendary flat catalogue for people working with Magento 1 – that are no longer treated as performance upgrade changes. It is good to remember about this as some older developers might want to change this to an unpreferred option. 

During configuration, it is good to check and correctly set up the indexations. Currently, most of the indexes are recommended to be set up to upgrade on schedule (except one) and I cannot think of any cause (stocks, prices) that should change that, as it will highly impact performance. 

A particularly good thing is also to acknowledge the size of the catalogue and get the number of effective SKUs – it is what we call a total number of rows and versions of the product. This is simple to calculate as it is the number of SKUS x websites x customer groups.  

If you have, for example, only 10 000 products but 5 websites and 3 different customer groups this is actually 150 000 effective SKUs, which is a lot. Thanks to that, some minor configuration changes could be done to the catalogue to make it smaller – is the fifth website necessary? Could we remove one customer group? 

Traitement des commandes

L'un des éléments qui permettra à toute boutique en ligne de traiter de plus grands volumes de commandes est la gestion des commandes. Bien que cela semble évident, c'est souvent négligé. 

The first thing to look into is the gathering of orders. Adobe Commerce allows us to do asynchronous order gathering. Orders are placed in temporary storage and moved in bulk to the Order Management grid without any collisions (this is a configuration change and can be done at any time). It will slow down the processing of orders in the backend but allow the frontend to take in bigger bulks of orders at the same time. 

The second option is the processing of orders – it is always recommended to do that externally (ERP) and only update the status in Magento using APIs. Also, the frequency of such updates is important – if it is happening in bigger bulks, for example, only once a day with more than 5 thousand rows, then it is worth pushing it through a queue system. 

Extensions tierces

Magento est connu pour son nombre considérable d'extensions – gratuites ou payantes. L'un des atouts de la création d'une boutique en ligne sur Magento réside dans la possibilité d'utiliser ces 3rd des solutions tierces pour livrer rapidement un MVP étonnamment bon. C'est là que cela devient délicat, cependant – il existe un risque substantiel de problèmes de performance lors de l'utilisation de fournisseurs externes. 

Premièrement, nous ne savons pas dans quelle mesure leur code est de bonne qualité. Certes, une équipe de développement interne peut réaliser un audit et déterminer si cette extension est acceptable ou non. Cependant, cela représente un coût supplémentaire et certains bugs peuvent parfois être difficiles à détecter. 

Secondly, even if extensions are well designed and coded and there are two or three of them working in the same place, handling the same data may add unnecessary points of failure. For example, if there are two extensions handling a display list of products, one allowing us to create a custom sorting order and another one to just add a sorting order based on sales – both could add 3 or 4 databases queries and slow time to the first byte by 100ms; 

La règle générale est d'éviter 3rd les extensions tierces, si possible, et s'en tenir à l'implémentation de base des fonctions disponibles dans Magento. 

Logique métier personnalisée

This is rather simple – each time you add custom business logic to Adobe Commerce, you are by default slowing it down. If your main goal is performance, then each time a new customisation must be developed, you need to ask the ecommerce team behind the shop if it is really needed. Perhaps there is some way to avoid it and use Magento core functionalities instead. 

Mais s'il n'y a aucun moyen de l'éviter, voici quelques points importants à surveiller : 

• Tout d'abord, assurez-vous que la structure de la base de données est bien architecturée et que les tables disposent des clés primaires, des clés uniques et des clés en général correctes pour chaque type de requête qui sera invoquée.
• Deuxièmement, assurez-vous que les préférences et les plugins soient aussi limités que possible. Chaque préférence et plugin présente un risque de perdre de précieuses millisecondes sur le time to first byte et, dans le cas d'une requête ajax, cela pourrait être très problématique.
• Réalisez le moins de transformations de données possible.
• Gardez toujours à l'esprit l'évolutivité. Assurez-vous que l'architecture et le code peuvent fonctionner sur de nombreuses instances et ne seront pas en concurrence pour les mêmes ressources de base de données.

Actions orientées performance dans le code

Optimising code for performance will always be one of the most impactful ways of making a web shop faster, but also one of the most difficult and costly. This always ends up taking a great amount of developers’ time and it is not always easy to perform as it often means a lot of refactoring. If all the new customisation code is done correctly from the start and undergoes unit tests, functional tests, and integration tests, then there is a high chance that few senior engineers can shave off every tiny bit of millisecond from running the code. Otherwise, it would be an ongoing struggle. 

Voici quelques méthodes efficaces pour lutter contre l'optimisation du code : 

• Évitez les boucles – déterminez s'il existe un moyen d'obtenir des données plus précises, afin de ne pas avoir à parcourir une collection complète de produits ou de commandes.
• Différez les requêtes externes telles que les curls – utilisez RabbitMQ ou planifiez-les et utilisez des données mises en cache.
• Évitez de multiplier les transformations de données – efforcez-vous d'opérer sur des valeurs aussi proches que possible de l'original.
• Essayez de ne pas utiliser plusieurs instructions « if-else » et ne les imbriquez pas.
• Vérifiez si Magento dispose déjà de cette fonction – souvent, certaines actions dans le back-end sont déjà définies dans le cœur de Magento (comme la sérialisation, les calculs de taxes, etc.) ;

Actions axées sur la performance sur le serveur

This is an overall statement as for optimal resource usage, we would suggest using a cloud solution (Azure, AWS or any other). The main point of interest here would be automatic scalability and separating different instances for different usage if possible.  

A good example of this is having separate servers for the frontend and separate for the backend but we could go much further than that and have additional instances dedicated only to the administrative backend (admin panel) or just for checkout routing. This way, CPU and RAM performance drop on the entire site could be easily mitigated and it would affect only one part. Of course, there is still a database issue, but this one could also be handled with a typical primary/secondary device configuration. 

Cela devient problématique lorsqu'il s'agit de nombreuses commandes qui s'ajoutent à la table des commandes et la modifient. Dans un tel cas, hormis l'ajout de puissance pour l'instance de base de données primaire, nous ne pouvons que mieux la configurer au niveau de MySQL/MariaDB/Aurora. 

Une liste de bonnes pratiques serait : 

• Changez toutes les tables de la base de données en InnoDB, car certains fournisseurs externes pourraient encore utiliser MyIsam.
• Il est toujours bon de vérifier max_connection s'il est correctement configuré.
• Une bonne modification de configuration consiste à définir innodb_buffer_pool_size autour de 1 Go si vous disposez de plus de 8 Go de RAM sur l'instance de base de données.
• Un autre élément à vérifier est souvent une valeur par défaut pour innodb_io_capacity, et dans un environnement cloud avec des disques SSD, il vaut la peine d'augmenter cette valeur.

Un dernier point à examiner est configuration php-fpm. Cette partie peut s'avérer délicate, car par exemple dans l'environnement cloud, il n'existe souvent pas de moyen simple de la configurer.

The default sample file that is present in the Magento git repository is quite good for starters, but pretty quickly there will be a need to change it, beginning from a “pm” value to on-demand if it was not already so, and pm.max_children to account for more RAM (RAM divided by max child pool size value, typically around 100MB); 

Cache et CDN

The last layer of performance tuning and the first layer for clients to see is cache. There are a few layers of cache that can be used with Magento, starting from Redis as a backend cache for blocks, going through full page cache like varnish and ending on CDN that will deliver some files like JS scripts and images from the closest possible server.  

The more you cache, the more you should gain (in theory) – but there is a bad side to cache. The information we are sending to clients may be outdated. So, like always, there is a long journey to find the sweet spot of how much we can cache and what cannot be cached. 

However, for CDN, this is always a thumbs-up. If possible, it is better to defer image loading (and optimising) to external sources. Fastly and Cloud flare, for example, can deliver images quicker and send better-optimised web images directly to clients. 

Résumé

Pour résumer l'ensemble de nos conclusions : 

• L'optimisation des performances commence avant même le développement effectif de la boutique en ligne.
• Dès la phase de discovery, nous devons trouver des réponses aux questions suivantes : Cela aura-t-il un impact sur les performances ? Si oui, est-ce nécessaire ?
• Utilisez uniquement des extensions tierces validées par l'expérience et bien connues.
• Si possible, évitez d'utiliser plus de quelques extensions tierces.
• Ne faites pas d'économies sur la configuration du serveur/cloud – il vaut mieux investir davantage dans la configuration initiale que de dépenser plus à chaque reconfiguration ultérieure.
• Investissez dans un mécanisme de mise en cache et un CDN – cela permettra au site de monter en charge rapidement.

Bonnes questions à poser à l'équipe de développement : 

• L'indexation et la mise en cache sont-elles activées ?
• À quelle fréquence les imports/exports seront-ils traités et quel sera leur impact sur le front end ?
• Des tests unitaires / tests fonctionnels sont-ils présents ?

Bonnes questions à poser à l'équipe métier : 

• Où les commandes seront-elles traitées et à quelle fréquence ?
• S'il y a une demande de nouvelle fonctionnalité, qui utilisera cette fonctionnalité ? À quelle fréquence ? Est-ce que cela en vaut la peine, (non seulement d'un point de vue commercial mais aussi en termes d'impact sur la vitesse globale de la page) ?