WooCommerce stores are rapidly becoming a more popular choice for shopping. In order to have a high preforming store that meets the customers’ demand at scale, you need to start with a well-optimized WooCommerce site. Once you achieve good performance for WooCommerce at low to moderate traffic levels, there are a few ways to maintain performance and availability at scale. The measures below will guarantee a high performing WooCommerce store that stays up and running even during heavy traffic shopping season.
First Step: Design a Store Well Suited for Scale
The key to survive shopping season and make good profits is making sure that your store can handle lots of traffic without crashing or shutting down. To make this possible is by developing an elastic architecture for the site or store. Elastic architecture is having the ability to run the WooCommerce site over multiple machines at one time. To have a successful site, the site must be able to go beyond a single server to scale. Elastic architecture allows you to be prepared for an uptick of traffic in your site. For a holiday season, it would be a good tool to utilize and facilitate more machines to run your website. It also works in the reverse; if a slow time hits your website, you may turn off the extra capacity to save resources. Elastic architecture keeps your website or store scalable.
Elastic architecture also makes sure that the site is “Highly Available”, which is the concept of not relying on a single server or machine. Another term for this concept is “horizontal scalability”, which is due to the fact that the diagrams for this concept are drawn in a four-square group. The drawing depicts the scale to be shown “horizontally” moving.
Another point about “high availability” is that if you add the capacity horizontally, the possibility of having some servers shut down while other servers carry the website exists. Also, if a database crashes, then a copy of the crashed database can be reciprocated to the new server. High Availability ensures that you are safe as far as having a single machine be the sole point of failure.
Such different architecture design approaches are responsible for allowing individual Word Press sites to be launched into billions of pageviews every day. Since nowadays people are using mobile websites more than ever, the use of architecture methods allows the developer to create a design suited for their needs, whether that be to boost machines to handle loads of traffic or contract the servers due to low demand.
There are a few challenges with elastic architecture. The mutual challenges facing elastic, horizontally scalable, and high available architecture are as follows:
- Load Balancing: The architecture methods mentioned above require a help in distributing traffic across available PHP App servers. Open-source tools like Nginx, and Pound can fulfill this role, but it can also be taken care of via hardware (like with an F5 appliance) or with a cloud-based load-balancer.
- Shared Media: Using WordPress as an example, they have a function for managing media (images, documents) to connect with posts on their sites. The media are placed in the uploads section of wp-content, but to successfully make WP horizontally scalable, media needs to be available for all PHP App servers. This also requires help from another source such as NFS, Ceph, and/or a cloud system.
- Consistency: When creating a group, or cluster, there needs to be consistency behind it. Each layer needs to have the same characteristics and configuration, otherwise the elasticity will not be compliant. Bugs may also arise as an issue from this poor planning. Also, any changes to the application itself, for example a WordPress core update, must be arranged constantly, which will require planning and thinking ahead. These presented challenges may be corrected using systems administrators and DevOps practitioners, as well as cloud tools.
Second Step: Caching
Reverse Proxy Caching
There are two types of caching models that will benefit your WooCommerce store’s performance. The first type is Reverse Proxy Caching. Reverse proxy is when requests and responses to or from a hosting site, such as WP, go through an intermediary service. The proxy serves as a cached replica of a response for a specific event. Caches may also be actively deleted or flushed.
For example, pretend that you receive a request from a visitor on your store’s homepage. For the very first request for the homepage, the reverse proxy doesn’t have a cached copy of the homepage and therefore it sends the request back to WP. WP generates the homepage of your site or store and serves the response. Then the reverse proxy sends the response on its way, but keeps a version for itself. Thus, during another visit by that user to your homepage, the reverse proxy can serve the response without having to connect to WP first.
Reverse proxy is a very useful method for scaling; it can be up to 1000 times more effective than a PHP server at sending cached responses. PHP web servers need to have a diverse amount of complex and tricky operations performed, such as connect to a database or process and execute thousands of lines of code. Reverse proxy just needs to deliver a static value from cache and the job is complete! Varnish is a popular open source reverse proxy, but you may also find Nginx helpful as a reverse proxy source. There are also hardware and commercial options available to developers. Some CDNs may also act as massive distributed reverse proxies. Products like Akamai, Cloudflare, and Fastly also work as globally-distributed reverse proxy solutions. These products and services will allow you to develop a site scale fit for high volume traffic and allow your site users to have a better experience. This positive experience will be due to the fact that they will have much faster response from being connected to edge serves located in an area closer to them rather than having them only connect to web servers in your local data center.
Some challenges to reverse proxy caching are:
- Cache TTL and Expiration: WP and the reverse proxy have to communicate through the use of HTTP headers and their job is specifying the lifetime, or Time To Live (“TTL”) of a cached page. This may require a bit more work because to actively expire or flush a cache means that the developer must create a mechanism for clearing the cache, and that is more beneficial than restarting the proxy each time.
- Complexity: Anytime a new system is introduced, the complexity of how to navigate the system may confuse many developers. Also, not having the web-browser communicate “straight” to WordPress, may further the complexity around how to debug issues. Be sure to take the time to make everyone on the same level as far as implementation of the system goes. That will help your team be less confused with the complexity of the new system.
Object caching is similar to reverse proxy caching because it is becoming an integral part of the world of software development. From Facebook to Google Docs, it is a required element to every large-scale application architecture. Most importantly, it is required for WordPress sites and stores. Persisting database objects with a high-performance storage backend is a requirement for scaling WordPress, especially for logged in users and dynamic content pages. If such backend wasn’t in place, the incompetence of resending the data in the object cache would begin to decimate the performance of your website or store, especially in instances with site complexity and dynamic traffic increase.
There is the possibility to persist objects using a single PHP instance, but scaling your object cache entails sharing persistence layers among PHP application servers. If a developer doesn’t share the persistent object cache values between PHP application servers, then they will run into trouble such as “cache (in)coherency”. This is when the application servers have diverse versions of cached objects and lead to buggy performance. Also, with all the object caching going on with WP automatically, it’s of even more value for developers when improving a specific use case. The challenges of serving varying data to numerous concurrent logged-in users or high volumes of traffic, are often the difficult situations that developers love to think over and come up with a solution.
WordPress stores its object cache as simple named key=>value pairs, thus there are multiple backends that can serve as a persistent object cache. The most well-known and used open source tools for persistent object caching are Memcached and Redis. Additionally, there are cloud services (e.g. AWS’s ElastiCache, Azure’s Managed Cache) that provide the same functions.
Challenges that revolve around object caching include:
- Complexity: Object caching adds yet another layer to the database and can pose a challenge of how to run the layer operationally along with everything else. Also, you will need to ensure that you have the same object caching solution available for development environments and as part of the acceptance testing or QA process
- Invalidation: If you have a site or store that is actively utilized, then WP data will be updated often. But it would be wise for you not to have this activity to take away from or invalidate the object cache with the same frequency. You also may need to perceptively eliminate specific keys within the object cache.
- Eviction: Many common cache backends have storage limits, and use a LRU (least recently used) approach for “evicting” items from the cache when more room is required. This may lead to unexpected expirations and can sometimes complicate developers’ work.
- Optimization: Implementing persistent storage backend to cache objects for a very dynamic application is not as simple as executing a full-page cache. You will be required to smartly cache data based on the following equation: of how expensive it is to generate, how frequently it’s requested (in other words, the likelihood of actually being served), and how much capacity is available in your persistent storage backend.
Third Step: Database Scaling
Your WooCommerce site’s database is the definitive bottleneck when scaling. The two caching strategies outlined above are in place to prevent load on the database. First, by handling pages before they pop up on WP and then by making WP not as dependent on the Database. You will soon discover that you will also need to scale your database to take care of a high volume of read requests (SELECT queries). An elastic architecture also provides you the ability to increase the capacity of your database through the use of replicas.
WP has had support for scalable read replicas for a while now, through the HyperDB plugin. This gives you the ability to scale out, and also to implement detailed strategies for how queries use the master and replica instances. One example of this is that it is simple to configure your site or store to use the master database for all specific requests related to administrative or logged-in functionality, while utilizing replicas in regard to anonymous traffic. This continual pattern makes sure that content editors always have the ability to use the site, even if it’s under sustained substantial load for normal content reading use.
Database scaling does not come without a few challenges in its path. They are as follows:
- Query routing: The HyperDB plugin has a few options for allocating queries across your database instances, but the best option is to keep it as simple as possible for starters. While your specific use-case may necessitate some customization to occur, the most efficient process is to diminish the amount of change and moving parts is to take the first step away from a monolithic single-instance implementation.
- Replication lag: In a perfect world with ideal circumstances, the replication lag is perfectly prompt. But not all circumstances are picture perfect; you’ll have to make sure that your implementation is able to handle multi-second lag. You’ll also have to monitor if the lag rises to unacceptable levels or if replication breaks down altogether.
- Debuggability: When handling wearisome queries, you must be able to access the slow query log, as well as have the ability to also safely and consistently replicate the situation resolve the issue. This means having an environment to debug in, along with all the data required to trigger the slow query. It may also mean taking the time to isolate and control where in the site code the query is being generated. This will allow time and resources for an alternative to be implemented.
- Regressions: As noted in the challenge above, the repercussions from a query of death can be immediate. For sites with large datasets, it is crucial to consider the impacts of new queries, as well as to test them before they are released into production.
Elasticsearch: Speeding up Product Searches for WooCommerce Stores
WooCommerce sites all require similar features; good product search, fast filtering of products and easy product discovery. The developer of the sites and stores often decide how to implement the features for themselves. Usually the way this comes about is by installing a plugin that would solve these issues of by building the functionality of the features by the developers.
ElasticSearch is the solution that every developer should utilize for their WooCommerce store. ElasticSearch is an enterprise level search server that is built on top of Apache Lucene. This search server provides a distributed full text search service that communicates via JSON over HTTP. ElasticPress is a plugin of ElasticSearch that also handles the indexing/syncing functionality within WP. ElasticPress does some easy maneuvering with the WP_Query class so that you may use it to query ElasticSearch. For example, to fetch 20 posts:
'ep_intergrate' => true,
'post_type' => 'post',
'posts_per_page' => 20,]);
Notice that a developer would only have to set the “ep_intergrate” argument to make this work. In some cases, such as search, the flag is not needed. This means that a developer can make a site’s existing queries Elastic well-suited with minimal effort. This works effectively with WooCommerce through a module that runs filter and product category queries within it. This may seem like a good solution, but there could be better. There are some practical defaults that developers like to have with all of their WooCommerce sites, and the task of building a plugin that forms a tighter bond between ElasticPress and WooCommerce is eminent.
The new plugin aims to utilize Elasticsearch’s built in filter generation functionality. The ElasticSearch API for this is called aggregations. You can replace the sidebar and run a custom aggregation query into ElasticSearch.
Not only are there filters out there that can render quickly, there are filters that also allow developers to utilize Elastic’s built in features. For example, a developer now has the ability to render a price filter that allows users to choose what price range they are looking for certain products to be in. Developers can also sort the aggregations into a tree structure and allow themselves to specify the depth of the filters.
These filters allow the clients and customers to decide what filters they would like to show per category page, which is quite novel; this hasn’t been possible before. Filters may also be taken through AJAX, which is a huge implementation on its own. You can even go another step further and add on infinite scrolling on all categories and shop pages so that users don’t have to worry about taking an extra step to view more products. There are also ways through ElasticSearch where products are easier to find via adding autocompletion to the search bar. This boosts their user experience and will promote traffic to your WooCommerce site. ElasticSearch is a desirable tool for developers and WooCommerce site users. This will allow your website to run more rapidly, without compromising efficiency.
Development and Workflow
When you have a highly efficient WooCommerce store that has heavy traffic and is scaled to handle the high traffic, you will be working with multiple engineers and developers to handle the site. One of the big tasks with WordPress at scale is the developer experience. Agile development workflows are a whole discipline, and one should take the time to familiarize themselves with how to establish a well-functioning team. Anyone interested in developing for Scale should strongly consider adopting both Pull Requests and Continuous Integration. To achieve these, one will need to have every change to the website codebase tracked in version control, preferably Git which is widely considered the industry standard. Developers will also need tools such as workflow documentation, and preferably some automation, to follow the processes correctly.
Challenges of development and workflow will arise. Below are a few areas to look out for:
- Site Configuration: the configuration of WP sites is forever in a tricky in-between state. Frequently you’d like to deploy config changes along with code, but most configuration is stored in the wp_options table in the database. The best answer is to utilize the WP-CFM plugin, which allows one to export configuration to JSON, and then to track it in version control along with code.
- Local Development: while the superiority of virtualization tools is continuing, they are still quite complex and require their own upkeep; losing a day of productivity due to local dev problems is unnecessary time lost.
- Setup Cost: setup costs for platforms or scripts can be a costly investment of time and may not be supported from a budget perspective.
Although scaling WooCommerce seems like an impossible project, planning in advance and implementing these solutions in Dev and QA environments are the keys to success. If you need a partner that’s experienced with scaling WooCommerce and has experts available 24×7, checkout our managed WooCommerce services. You can use ScaleDynamix platform to scale WooCommerce on your current cloud provider and gain better performance while using fewer resources.