How to Avoid Problems With E‑Shop Operation Resulting From Server Load
E-commerce platforms, especially B2C systems, are often characterized by the seasonality of sales. Various holidays or promotional campaigns represent periods of intensive work across the entire enterprise. They’re also often filled with stress and anxiety resulting from fears about the efficiency of the IT system. The more complex the systems are – and the larger the gap between the worlds of business and technology – the more this uncertainty grows. This article will help you to understand how you can avoid problems resulting from inefficient technology, and thus sales organics.
The best place to start discussing the speed of an online shop is by understanding what constitutes the time that elapses between the execution of an action by the user (e.g. entering the website, launching a product search) and the expected result. Without going into details, we can divide this time into:
- network transmission time
- processing time of the request by the servers
- time of displaying the results by the user’s device
Depending on the structure and placement of the system, geographical dispersion of shoppers, or devices used, each of these elements will have a different impact on Customer Experience. While it might seem that network speed is no longer an issue, it’s no problem finding stores where unoptimized graphics needlessly increase the display time of product cards. At the same time, there is an increasing use of public clouds with very detailed price lists, which immediately transfer transmission costs to the system owner. So it’s worth looking at whether the team preparing graphic materials applies good practices, whether the quality of images presented in large quantities is sufficient (not necessarily the best possible), and finally whether mechanisms are being used to shorten the path from servers to screens, such as a Content Delivery Network (CDN).
Do you know how efficient your system is?
The owners of shops operating on standardized SaaS platforms have a slightly easier task – they can get an answer to this question from their platform provider. However, if they base their strategy on distinguishing themselves from the competition (e.g. building unique shopping experiences based on platforms like WooCommerce or Magento), then should then measure the platform’s performance themselves. The experience boasted by the implementation partner makes it possible to some extent to estimate the theoretical performance of the system – but that’s just theory. When we seek a guarantee of fast operation, it turns out that a slightly different hardware platform, unique features, integration or even an unusual product catalog make it impossible to give a reliable answer.
What’s the solution? The natural answer “let’s do performance tests” isn’t always the best idea. Why? For a simple reason: the verification of hypothetical situations is not cost-effective.
How to properly define the problem?
Before commissioning performance tests, you need to know which question you want to answer, because different problems will require different approaches. Remember that the system as a whole will ultimately be as efficient as its slowest element. Here are some examples of issues that should be reviewed:
- How many simultaneous users is the shop able to serve?
- How many transactions can be executed per unit of time?
- What is the maximum momentary load (audience, number of transactions) the system will withstand? Is it ready for Black Friday events?
- What determines the operation speed of the end user’s shop (see chapter above)?
- Does the shop have features that are unusual for a given technology, e.g. a very complex product catalogue structure, strong customer segmentation and personalization (recommendations, prices), large number of products?
- Will the systems integrated with the store be able to handle the expected number of customers, orders, inventory variations, etc.?
In practice, only some of these questions are answered by performance tests, mainly due to the costs of preparing all the separate tests to check each area separately. The most important thing is that such questions should be posed and that the e-commerce implementation team should pay attention to each of them, proposing a method for obtaining answers to a given question. Sometimes it’s enough to analyze the history and compare it to a similar implementation in another client; sometimes it’s enough to review the statistics on database query execution times and optimize the heaviest and most frequently performed queries; sometimes it’s necessary to build an advanced test profile using an application like JMeter and check the efficiency of the purchasing process on the test environment. One thing is certain: the more general question you ask, expecting the simplest possible answer (e.g. “can the shop do it?”), the more you risk an unpleasant surprise. It is important to break performance requirements into primary factors and analyze them one by one. Make sure this gets done!
How to predict the future?
Contrary to appearances, there is no need for a crystal ball. Most retail businesses are not created out of thin air – they are rarely built in great secrecy, in isolation from the Internet, in order to enter the online scene at the right moment with momentum and quickly take over half of the market. Mostly organic development allows for systematic data collection:
- on user behavior (e.g. use of Google Analytics),
- about individual components of the system (application servers, databases, search engines, caches, etc.)
- about changes in the application (new functions, integrations, functional conversions, etc.)
It’s best to start this monitoring as early as possible, preferably before the launch of the production store. Internal tests will tell us whether the monitoring is complete and whether there are any elements in the application that, even with little movement, raise doubts as to speed. Absolute values of indicators such as percentage load of processors, number of running processes or disk operations in time will allow an experienced engineer to assess the health of the system. Much more accurate diagnoses will be made when we have comparative material at our disposal. That is why it is so important to have a longer history of monitored parameters. Often, the mere characteristics of the graphs allow us to conclude whether the system will behave stably at a higher load.
With a well-monitored system, the inclusion of small promotional campaigns in the process of building e-commerce gives the team an additional opportunity to observe the relationship between what is promoted and how it is promoted, and statistics on audience and server load.
Communication is key!
However, there is one condition: good communication between the promotion teams and those responsible for the development and maintenance of the store. These teams must exchange knowledge about the dates and scale of planned promotions, their effects, visible bottlenecks and expected limitations of the system. Likewise, the implementation of new functions, the appearance of more complexity in the system or more data cannot be kept secret from any of the people co-responsible for the shop’s operation. The lack of good knowledge flow can inevitably lead to slower operation of the shop (and thus reduced revenues). What is more, it will take too long to diagnose the perceived problem, while it would suffice to recognize that the platform is using a new integration that may correlate with its slowdown. The importance of a good store development project is clear to see.
Your system’s in the cloud, so Black Friday won’t take you by surprise?
Well, not necessarily. The key issue is how the system was built. A simple transfer of an ordinary, “sandwich” installation, e.g. Magento, from its own servers to virtual systems in a public cloud may allow you to prepare for increased load, at least to a certain scale. Changing from a virtual system to one with 96 processors? Why not? But are you sure that paying a few dollars for each hour of operation will make this “fun” remain profitable? And what if a single server fails, which can happen to even the best cloud providers? There is no public cloud provider that gives 100% SLAs for a single virtual system.
Deciding to build a shop based on one of the three leading public clouds (Amazon Web Services, Microsoft Azure, Google Cloud Platform), you have much more room for maneuver than in the case of a traditional data center. However, for the system to be ready for high traffic without eating up the project’s budget, it must be optimized for operation in the cloud. If full and automatic scalability used for your application or database is difficult to implement without introducing significant changes in the code, it is almost certainly possible to break down individual components into virtual systems with matched parameters, use a Content Delivery Network, setting caching policies or adequate preparation of space for serving static objects. In this way, even a shop built on a platform that was not natively designed to operate in an autoscalable environment and based on highly accessible cloud services can be significantly “upgraded” and prepared for the expected load.
Preparing a shop for sales is not rocket science. And it certainly does not require a thorough knowledge of technology from its owner or head of e-commerce. This article has taught you about the most important issues that you should have in mind when managing the cooperation of teams working on the development of your store. Considering and deepening this knowledge from the beginning of the process and cultivating a culture of openness and cooperation in teams give you the best chance for success.
Remember:
- The speed of a store does not always depend on servers.
- Server performance is a multidimensional issue – use the help of specialists to properly define the problem.
- Ensure early start of data collection on shop visits and system performance.
- Ensure good communication between engineers and the rest of the company.
- The cloud does not always guarantee success – system architecture is important.
