Magento عالي الكفاءة – كيف تتعامل بسهولة مع 8000 طلب يوميًا في Adobe Commerce

ما ستتعلمه بعد قراءة هذا المقال:  

• ما العمل المطلوب على جانب Adobe Commerce للتأكد من قدرته على تحمّل الحمل؛  
• ما العمل المطلوب على جانب الاستضافة/السحابة للتعامل مع هذا العدد الكبير من الطلبات؛  
• ما الأسئلة التي تحتاج إلى طرحها على فريق التطوير للتأكد من استعدادهم؛  
• ما الأسئلة التي يجب أن يجيب عليها فريق الأعمال للتأكد من جاهزية شركتك؛  

ما الفرق بين Magento وAdobe Commerce (و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;  

To cap it all, there is also Adobe Commerce in the Cloud. It’s basically just Adobe Commerce in a predefined cloud solution that Adobe upsells to their customers; Whether it’s effective in terms of cost and performance is a whole different story.   

لنبدأ من البداية. 

التكوين

All basic configuration that could be done on the Magento side does not affect performance. However, if you start going deeper, some minor changes to one or two options could, in fact, make the site twice as slow. 

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? 

معالجة الطلبات

أحد العناصر التي ستسمح لأي متجر إلكتروني بالتعامل مع كميات أكبر من الطلبات هو معالجة الطلبات. وعلى الرغم من أنه يبدو أمرًا بديهيًا، إلا أنه غالبًا ما يتم التغاضي عنه. 

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. 

إضافات الطرف الثالث

يشتهر Magento بعدد كبير من الإضافات – المجانية أو المدفوعة. ومن نقاط الجذب لبناء متجر إلكتروني على Magento إمكانية استخدام تلك الـ 3rd حلول الطرف الثالث لتقديم منتج أولي جيد بشكل مفاجئ بسرعة. لكن هنا تكمن الصعوبة – فهناك خطر كبير من مشاكل الأداء عند استخدام موردين خارجيين. 

Firstly, we are not sure how good their code is. Sure, an internal dev team can do an audit and say whether this extension is ok or not. However, that is an additional cost and sometimes some bugs may not be so obvious to find.  

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; 

القاعدة العامة هي تجنب 3rd امتدادات الطرف الثالث، إن أمكن، والالتزام بالتنفيذ الأساسي للوظائف المتاحة في Magento. 

منطق الأعمال المخصص

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. 

ولكن إذا لم تكن هناك طريقة لتجنبه، فهناك بعض الأمور المهمة التي يجب الانتباه إليها: 

• أولاً، تأكد من أن بنية قاعدة البيانات مصممة بشكل جيد وأن الجداول تحتوي على مفاتيح أساسية صحيحة، ومفاتيح فريدة، ومفاتيح بشكل عام لكل نوع من الاستعلامات التي سيتم استدعاؤها.
• Secondly, make sure that there are as minimal preferences and plugins as possible. Each preference and plugin poses a risk of losing valuable milliseconds from time to first byte, and in the case of an ajax request, this could be very problematic. 
• نفّذ أقل عدد ممكن من عمليات تحويل البيانات.
• ضع دائمًا قابلية التوسع في الاعتبار. تأكد من أن البنية البرمجية والشيفرة البرمجية قادرتان على العمل على العديد من النسخ ولن تتنافسا على نفس موارد قاعدة البيانات.

إجراءات موجهة نحو الأداء في الكود

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. 

بعض الطرق الفعّالة لمكافحة تحسين الكود هي: 

• تجنّب الحلقات التكرارية – اكتشف ما إذا كانت هناك طريقة للحصول على بيانات أكثر دقة، بحيث لا تضطر إلى التكرار عبر مجموعة كاملة من المنتجات أو الطلبات.
• تأجيل الاستعلامات الخارجية مثل curls – استخدم RabbitMQ أو قم بجدولتها واستخدم البيانات المخزنة مؤقتًا.
• تجنّب عمليات تحويل البيانات الكثيرة – حاول العمل على قيم أقرب ما يمكن إلى الأصل.
• حاول عدم استخدام عبارات "if-else" متعددة وعدم تضمينها بشكل متداخل.
• تحقق مما إذا كانت Magento تمتلك هذه الوظيفة بالفعل – فغالبًا ما تكون بعض الإجراءات في الواجهة الخلفية محددة مسبقًا في نواة Magento (مثل التسلسل، وحسابات الضرائب، وما إلى ذلك)؛

إجراءات موجّهة نحو الأداء على الخادم

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. 

It becomes problematic when we are talking about many orders adding to and changing orders table. In such a case, except for adding more power for the primary database instance, we can only configure it better on MySQL/MariaDB/Aurora level. 

قائمة بالممارسات الجيدة ستكون: 

• غيّر جميع الجداول في قاعدة البيانات إلى InnoDB، إذ قد يستخدم بعض الموردين الخارجيين MyIsam.
• من الجيد دائماً التحقق max_connection إذا تم إعداده بشكل صحيح.
• من التغييرات الجيدة في الإعدادات ضبط innodb_buffer_pool_size على حوالي 1GB إذا كان لديك أكثر من 8GB من الذاكرة العشوائية على نسخة قاعدة البيانات.
• هناك أمر آخر يجب التحقق منه وهو غالبًا القيمة الافتراضية لـ innodb_io_capacity، وفي البيئات السحابية المزوّدة بأقراص SSD، يجدر زيادة هذه القيمة.

الأمر الأخير الذي يستحق النظر هو إعداد php-fpm. قد يكون هذا الجزء صعبًا، فعلى سبيل المثال في بيئة السحابة، غالبًا لا توجد طريقة مباشرة لتهيئته.

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); 

ذاكرة التخزين المؤقت وشبكة توصيل المحتوى

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. 

الملخص

لتلخيص جميع النتائج التي توصلنا إليها: 

• يبدأ تحسين الأداء حتى قبل التطوير الفعلي للمتجر الإلكتروني.
• منذ مرحلة الاستكشاف، نحتاج إلى إيجاد إجابات للأسئلة التالية: هل سيؤثر ذلك على الأداء؟ إذا كان الجواب نعم، فهل هو ضروري؟
• استخدم فقط الإضافات الخارجية المعتمدة من جهات موثوقة والمُثبتة بالتجربة.
• إن أمكن، تجنب استخدام أكثر من عدد قليل من إضافات الأطراف الثالثة.
• لا توفر على إعدادات الخادم/السحابة – من الأفضل إنفاق المزيد على الإعداد الأولي بدلًا من إنفاق المزيد على كل إعادة تهيئة لاحقًا.
• استثمر في آلية التخزين المؤقت وشبكة توصيل المحتوى (CDN) – سيساعد ذلك الموقع على التوسع بسرعة.

أسئلة جيدة لفريق التطوير: 

• هل الفهرسة والتخزين المؤقت مفعّلان؟
• كم مرة ستتم معالجة عمليات الاستيراد/التصدير وكيف ستؤثر على الواجهة الأمامية؟
• هل توجد اختبارات وحدة / اختبارات وظيفية؟

أسئلة جيدة لفريق الأعمال: 

• أين ستتم معالجة الطلبات وكم مرة؟
• إذا كان هناك طلب على ميزة جديدة، من سيستخدم هذه الميزة؟ وكم مرة؟ وهل تستحق ذلك، (ليس فقط من منظور تجاري بل من حيث تأثيرها على سرعة الصفحة الإجمالية)؟